In my applications I generally use SQL Instance enumerator to get all the instances of SQL Server. But I've found that running a firewall and/or internet security doesn't allow the application to access the instances. For this, I've to advise the person to turn off the firewall so that it can access the instances which isn't a good idea. I googled but I found some batch file scripts that work for particular Windows version (Windows Server 2008, XP etc).
But I want to know some generic script or method which opens the ports for SQL Server on any machine. How do I resolve the issue?
You'll probably find this link, and this one useful (C# code).
Maybe also some powershell scripts would do the trick: here and here
But it's about Windows Firewall only. Keep in mind there are different software firewalls on the market, and most of the time there also is an hardware firewall (sometimes more than one).
Related
I am fairly new with MS Azure and developing remote apps.
Have read and viewed some learning stuff.
I use c# as my developing language, and as I have understood, its fairly simple to develop a windows application to run on an Azure server as remote app, which users anywhere on earth can run from their pc as if it was installed locally on their pc's. But in reality, it is more like, an RDP hiding behind the app.
The problem is that a database will be running on every users pc instead on the azure server. It is suppose to be like that by design, don't ask me why.
We tend to use "ms access" for the local DB, since everyone already have MS Office.
Anyway, back to the problem. What I am wondering is, how can I make my remote application on azure server communicate with the database installed locally on user(s) PC?
I have drawn a simple figure to explain what I mean.
http://snag.gy/ybyed.jpg
Back in the days when people used Modems to connect their PC's to the tubes, this would be theoretically possible (although maybe not a good idea). Nowadays, very very few PC's are connected directly to Internet.
In an Office, a PC will be connected via the company intranet to an external gateway and the PC will not be visible to anyone outside that gateway. The same is true at home, where the gateway is the router.
It would be possible with a lot of work to allow external access (from Azure) to the individual PC, but it would not be easy to set up. Further, you would need to write a piece of software to run on the PC which will listen on the correct Port for calls from Azure, will then run the appropriate SQL queries, and return the data to Azure. You might as well install SQL Server full edition on each PC.
Even if you do that, no security professional is going to let you actually open up the ports and firewalls to the internet; it's a lot of work doing that and you might as well just install random viruses on the PC - you'll get to the same point but faster and with less wasted time.
TL;DR: Not easy without a significant investment, and your PC will probably get trashed if you do.
This is actually possible by the magic of RDP protocol :)
Azure RemoteApp supports redirection for Windows machines as documented here: https://azure.microsoft.com/en-us/documentation/articles/remoteapp-redirection/
So, once you create an Azure RemoteApp collection, you can download the PowerShell cmdlets, enter your subscription ID and then you can enable drive redirection. This results in the local disk being mapped on the remote machine. You can try it out and see if performance is good enough.
The other alternative is that the database lives in an Azure storage account, as documented here: https://azure.microsoft.com/en-us/documentation/articles/remoteapp-anyapp/ .
You should NEVER store data on the Azure RemoteApp local machine.
/cd
I'm working on a project that involves linking my C# application to a MySQL server. The server is running cPanel and the company does not allow all IPs to connect to it (although you can add host IPs to the remote list). The application will be running on Windows 8 Tablets on a 3G connection, so obviously I will not know the IPs if the devices to be able to add them to the list.
A collogue of mine has told me of a system, API or something like that that will allow me to interface with the Database via HTTP effectively bypassing this restriction.
I can provide more information if needed.
Does anyone know of anything similar to this or any way around this?
If you are using MySql 5.7 or higher, there is an experimental "lab" for allowing direct access to MySQL via a REST over HTTP interface, eliminating the need for a middle-tier server or database specific drivers.
You can download the plugin at the MySql Labs site. From the dropdown, select "MySQL HTTP Plugin" and you should be good.
Keep in mind that its part of the "MySql Labs" project, which means its experimental, probably buggy and should be used at your own risk. Think twice before using them on any kind of production server.
Is there a Windows (7) tool that traces which processes are creating local network connections to my service on the same machine?
Since a couple of weeks I'm seeing the creation of lots and lots of sockets that immediately (or at least very fast) get the status TIME_WAIT. This does not happen always, but regularly, haven't been able to find a pattern yet. I'm using netstat -a -b -n -o to find information about those sockets, but the only things that tells me is the end-point (which is my service), the status (always TIME_WAIT) and that the owning process is process 0, so not very useful.
There are of course other methods for analyzing this problem, but having a tool that pinpoints the exact process that creates this huge amount of sockets, will narrow down my search.
Some more background information: my service is an ECO WCF service connected to SQL Server Express 2008 R2. There are four web sites running locally in Visual Studio's WebDev.WebServer40.EXE, all of them will use the service at one time or another.
First I suspected a bug/bit rot in Visual Studio 2010 or my Windows 7 setup, so I did a fresh install, but the problems was still there.
Going back to previous versions of my service and applications does not fix the issue.
You could always have a look at a very handy tool called Process Monitor. It was developed by Mark Russinovich, and is now part of a Microsoft toolset.
It allows you to monitor lots of events, including thread creation, registry access, file access, and network activity. All of these events are on a per-process basis, so you should be able to use the filters to see what process is connecting to a specific port local port. I'm not sure if this would include UDP (which is generally connectionless), but certainly a quick test shows TCP Connect, Disconnect, Send and Receive events.
It's a very handy tool to add to your programming toolbox anyway.
I've designed a C# game that makes use of an Access .mdb database file to store variables.
The basic idea is that one of the players will 'host' a game, and the other player will join said game, by connecting to the database, reading and writing items into the database. The database is needed to pass variables to and fro the host and client, and both programs check the database regularly for new messages / variables (yes, yes, I couldn't get TCP/IP Remoting to work).
Now, there, the program works fine (mostly the client, since the host modifies only its local database), for as long as the client can find the database file. Currently, the connection string for the client is located in a .ini file, and for the program to work, it (or at least, the server) must be located in the Shared Documents of an XP machine, or the Public Documents of a Vista / 7 machine.
But then some questions occurred to me:
What if the client user places / installs it into another folder in the Shared / Public Documents? I suppose there's a code out there that could 'drill' into the Shared Documents folders to find the path for the database, share names included... is there?
What about installation? The installer default is always "C:\Program Files\GameName". Could it be set (or locked) to a specific folder into the Shared / Public Documents, by default? And is it even recommended to install it into a Shared Folder, what with problems such as Accidental Deletion?
Say, the default is "C:\Program Files\GameName". I could see that a set installation path will solve any connection issues, since every client will look in the same path of the other computer, and it won't matter if it's XP or Vista. Could "C:\Program Files\GameName" be accessible by a C# program over LAN, without any system modification? Are there any security (UAC?) issues?
P.S. Details that people may find in handy:
I'm using Visual Studio 2005. So is my School.
I'm running .NET framework 2.0. So is my school, and unfortunately, I can't change that.
I hate to tell you this, but this is why the approach is fundamentally flawed. What are you going to do when:
File and print sharing on the server is disabled?
The network client is disabled on a client computer?
The server is configured to only allow authenticated users, and the client doesn't have access?
File and print sharing is blocked because of the firewall?
File and print sharing is completely borked for other who-knows-why reasons?
You need administrator access on the server to share a folder, but the current user is not an administrator?
The Access database engine isn't installed correctly on the server or client?
One of the clients corrupts the database? (This is easier than you might think; all it takes is a network glitch where a client temporarily or permanently disconnects from the server).
These are fundamental issues that you can't resolve with the current solution.
Get it working over normal TCP/UDP ports. You'll have a much easier time. There are libraries to facilitate that, see C# Game Network Library - for example it sounds like Microsoft's XNA SDK has functions for networking in a game. If you use a standard method / standard library to implement networking, your odds of success are much higher. Using a client/server architecture means that the server's state won't be corrupted if a client goofs up.
I realize that this probably involves a significant rewrite. Frankly, I don't think you have a choice if you want this game to be commercially successful on a wide customer base without high support costs, and move beyond being a mere experiment.
Get rid of the access database. The described architecture is already 'user unfriendly'
Use either SQL Express or SQL CE which requires no installed database binaries (they can all be included in the applications folder). This way the db will stay in the applications folder (ideally app_Data) and .Net has included support for databases in this folder.
Please stay away from access you will save yourself a lot of trouble.
http://blogs.msdn.com/b/sqlservercompact/archive/2011/01/12/microsoft-sql-server-compact-4-0-is-available-for-download.aspx
I think that there is little point in using Access unless you wanted to use any of the pretty form-based IO that you can you do with its designer. And I doubt that'll be the case here.
I would encourage you to replace all your file IO with a sound data access layer.
Which will rid you of all the "sharing" issues that you are experiencing, file locks, the overcomplicated installation process, etc.
Alternatively to SQL Server Express as suggested above you could also use SQLite http://code.google.com/p/csharp-sqlite/
We have a .NET project that uses WMI and are interested in porting it to the Mono framework.
It appears Mono does not support WMI.
Are there any libraries that can add WMI support?
Basically we would want to access a Windows server using WMI from a Linux/OS X box.
Windows Management Instrumentation is a Microsoft implementation of WBEM (Web-Based Enterprise Management).
There are open-source implementations (eg openPegasus) that you might be able to use a client, but there's no telling what MS did with their version. If you can send CIM queries to the server, then you may get good results.
Note that Windows doesn't do WMI over http, only DCOM/DCE-RPC, so some clients will just not work. A quick google.. and OpenPegasus will allow you to access Windows using a WMI Mapper. If not, you could always run the server component on Windows.
Regarding WMI over HTTP, take a look at WinRM, which appears to be an implementation of WS-Management for XP, Win2003, Win2008, and Vista. This defines a way to access Common Information Model (CIM) information over HTTP(S) (SOAP). CIM is defined by the DMTF and WMI is Microsoft's implementation of CIM.
If I read the alphabet soup correctly, you should be able to use SOAP from Linux to access WinRM (WS-Management) on a Windows machine, thus providing access to WMI (as long as WinRM is installed, running, and not firewalled).
Whether running such a thing on a corporate network will be allowed by IT/Security is another matter entierely: any open port can be a security risk and one which allows command, control, and configuration by design can be quite a hole. Certificates, IPSec, and scoped firewall rules are your friend!
Note that I have no direct experience using WS-Management, nor WinRM, so YMMV.
I know you can install wmi-client on Linux (sudo apt-get install wmi-client). You should be able to query any wmi object on a Windows box from the Linux command line using this.