I am going to be coding up a windows service to add users to a computer (users with no rights, ie just for authentication). (As a side note, I plan to use this method.)
I want to be able to call this windows service from another computer.
How is this done? Is this a tall order? Would I be better off just creating a Web Service and hosting it in IIS?
I have some WCF services hosted in IIS on the calling computer (they will do the calling to the proposed windows service). I have found that Hosting in IIS is somewhat problematic, so I would rather not have a second IIS instance to manage unless I need to.
(I will be using Visual Studio 2008 SP1, C# and Windows Server 2003 (for both caller and service host).
Thanks for the help
If you are thinking of hosting a web service in IIS just to communicate with an NT-service on that same machine, that is definitely more trouble than it is worth in this case.
As other answers have indicated you can make a WCF service with the operations you need and host that within the same NT-service that you want to interact with. You can easily secure this with certificates, or user accounts to make sure it is only controlled by the right people/machines.
If you need to control the NT-service itself, there are existing programs such as sc.exe to start, stop, configure, or query the status of your NT-service remotely.
However, you may want to consider seeking a solution without the overhead of creating an custom NT-service and a custom WCF service to interact with it. If you do, the Net User commands (sorry no link - new user limitation) or the AddUsers (see kb 199878/en-us) utility may be sufficient. If your remote "controller" can invoke these commands directly against the target machine you may not have to create any custom software address this need. Additionally you would have less software to maintain and administer on the target machine. You would just be using the built-in OS capabilities and admin utilities.
Finally, you will need to think about the security aspect, NT-services and IIS are usually run under very restricted accounts, many auditors would flip-out over any service running with sufficient permission to create or modify users locally, and especially on other machines. You'll want to make sure that the service could never be used to create users that do have more than the "authenticate" permission you indicated.
Edit: The net user command may not work against another machine's local users, but check out. pspasswd that along with PsExec to create users, should do what you need remotely.
Simply host a WCF service in the Windows Service. You'll then be able to call it remotely.
You can host a WCF service inside a Windows service. Take a look at the TCP binding (NetTcpBinding class). Both client and server will have to use WCF, but that doesn't sound like it will be an issue with your implementation.
Also, the section entitled "Hosting in Windows Services" in this MSDN article provides a walk-through of the process
If the windows service publishes a remoting interface then it can be accessed via that remoting interface.
Otherwise it's the same as accessing any other process running on a remote machine except that there may be some tools (e.g., sc) with built in support for executing against a remote machine (barring firewall complications).
Any IPC mechanisms applies; sockets, web services, remoting, etc...
You could expose a WCF service directly from your windows service. When you start up your windows service, in addition to spinning up any other background processes, you could create an instance of ServiceHost<T> for your service implementation. This would allow you to not only provide WCF access, but also avoid the extra instance of IIS like you requested, and provide TCP, Named Pipes, and WsHttp endpoints. This should give you some nice flexibility in the performance tuning arena, since it sounds like this service will be consumed internally on your network, rather than externally.
You could create a WCF service which will talk to your Windows service on the remote box. Host the WCF component in IIS (or however you'd like so that you can communicate with it) and then call the WCF component from your remote machine.
Related
I have a windows network (not connected to domain) and I need to provide some automation on each PC at certain time of the day. There are several tasks - launch executables, managing FS, transfering files. All this actions must be implemented via RDP, using C#. What is common approach to achieve this? I don't have experience using RDP within software. So are there .NET classes or free libraries I can use to get RDP functionality in my software. Thank you!
All the tasks you have listed relyed much more on security issues for machines within your network and a user logged-in priveledges a rather than a usage of RPD.
Within a windows domain the tasks like yours are usually delegated to ActiveDirectory administration and policies.
In case of a not Windows Domain Network you will need to use a mechanism that will be presented in following configuration:
a client installed on each particular machine under proper permissions. The client should implement a subscriber pattern.
a server installed on a "commander" machine. the server should inplement a publisher pattern.
There should be a lot of ready solution that should implement the concept of content disribution and starting specific scripts. I think that your investment in such tools research and evaluation will be much more time- and cost- effective rather than writing an app that "uses RPD functionality"
But if there is a reason that prevents usage of 3rd parties, I would go for implementaion of WCF service that will be installed on all clients. This service should be "trained" to do all your suff on client. Server side you will need an appliaction or a service that will publish events for clients or trigger known clients methods.
WCF service can be hosted both in IIS and in Windows service. What are differences? Is there any benefit hosting in Windows service than IIS?
Check out the documentation: https://msdn.microsoft.com/en-us/library/ms730158%28v=vs.110%29.aspx
It is awesome!
And the answer to your questions depends on what kind of application you are building and other requirements on the application/environment...!
Here are some differences (Features of IIS.. Copied from the link provided by #Jocke).
You lose all of the features of IIS (logging, application pool scaling, throttling/config of your site, etc.)...
You have to build every single feature that you want yourself HttpContext?
You lose that since ASP.NET provides that for you. So, I could see that making things like authentication much harder WebDeploy?
IIS has some nice specific features in 8 about handling requests and warming up the service (self-hosted does not)
IIS has the ability to run multiple concurrent sites with applications and virtual directories to advanced topics like load balancing and remote deployments.
If your WCF serivce is self-contained, like a data service, just host it in IIS. Drawback: you'll have to install and configure IIS.
If your WCF service is more of an API or IPC mechanism, used to let other applications talk to your application, it makes more sense to let your application self-host the WCF service, and for that a Windows Service usually is the more sensible approach. Drawbacks: you'll have to install your application as Windows Service, and configure that your application may listen on its configured port.
Please note that self-hosting is not constrained to Windows Services.
I'm trying to create a client-server app where the server runs on the user's machine. I'm looking into either using WCF or Sockets but I have a couple of questions.
I'd like to use WCF but it seems that the user needs admin rights in order to launch the service. Would the user need admin rights if the WCF service was running within a managed application (e.g. a Windows Service)? With sockets it seems that admin rights isn't required to open the relevant port.
How would HTTPS security work in WCF? Since this is a LAN program (user talking from client to their own machine), do I need to purchase a certificate and install it on their machines? I'd rather avoid this if possible as the data being transferred isn't sensitive. Would this be the same if I use SSLStream for sockets?
There are a lot of questions, :), so very short answer on part of them:
You can host WCF even in console application. Windows Services may not require admin properties to be installed on pc.
For HTTPS - you does not have to buy certificate, you can crate your own - there are a lot of examples in the net. But - if your data is not sensitive - you can probably use simple http.
I have a WCF service hosted in a Windows service.
This service the WCF have one metohd and in this method I have one important line :
Process Browser = Process.Start("iexplore.exe", hostUrl);
I install Windows service as local system, but when I'm trying to invoke that method, everything seems to execute, except that one important line... and IE didn't open.
I would like to add that the method itself is not in the service itself but in one of the service dll reference
Any idea why?
http://social.msdn.microsoft.com/forums/en-US/netfxbcl/thread/63a7d1ec-7077-489a-a250-f7422f04317b
" in order to get the service to actually show the UI, you'd have to set the service in Computer Management to allow it to interact with the desktop. In the services window in computer management, go to the properties of your service, and on the Log On tab, check "Allow service to interact with desktop" "
Since Windows Vista MS has been adding lots of security-related changed esp. in the area what Windows Services can/can't do. Anything "desktop-like" (printing, accessing network shares, using Office Interop etc.) is harder and harder to get working.
You should rethink your design since IMHO any "server-like process" (for example a WCF service) can be accessed in parallel by multiple requests and thus should NOT use processes which are NOT designed for this type of interaction... what happens if your webservice starts multiple IE instances that way ? Will IE behave as you need/expect it ?
IF you really really MUST do it this way you should have
a normal desktop process hosting the WCF service
OR
two processes, one your Windows Service and one running as a normal desktop process dealing with IE... these two process communicate via IPC
Under what user is the service running? Try running it under the currently logged in user, with privileges to interact with the desktop and see if that helps.
In general, its not a great idea to have services launching GUI processes. For example, what if no one is logged on. What if many people are logged on? Should it open in all sessions... etc. Have you considered exposing a simple (e.g. Net.NamedPipes) endpoint on your service, and writing a small client UI to interact with it?
I have written a windows service in C# that gathers performance, disk and memory information and writes it to the EventLog. It is enabled as a network service. What I would like to do is be able to gather this information from a remote location. This service will run at various client machines and I would like to retrieve this information periodically (once a day) and store them in a database table. I am confused as to how one can query a windows service over a network. In other words, what exactly makes the service a "Network Service"?
I do not want the service to directly connect to my database and write this information. But I would like to initiate it from a remote machine, retreive the information and then write that information to my database table.
I was unable to find any tutorial that illustrates a networked windows service. Most of them covered writing to event logs and I am pretty much stuck there.
Is this doable, are there any suggestions about how this sort of stuff is done?
If the other suggestions to move over to WCF Web services are not an option, you can do allot with Custom commands in a windows service without having to resort to remoting.
Effectively you can send an integer between 128 & 256 and then have your service execute whatever code you need it to when it receives that command, like sending all the information to your database or web service.
You will be able to initiate it from your side as and when you need to while the service happily trundles along on the client machines.
Take a look at this code project article for an example: Creating a Basic Windows Service in C#
Take a look at the OnCustomCammand method.
Here's another example article from Microsoft: Communicate With Windows Services
Use WCF to enable some form of a RESTful Web Service.
See wcf-getting-started on MSDN, and specially A Guide to Designing and Building RESTful Web Services with WCF.
AFAIK 'Network Service' just means that it is running under the "Network Service" account which has a different set of permission than the 'Local Service' or 'System' accounts.
To expose a service to another machine on the network however (apart from the standard STOP, START, RESTART functionality that you get through the services snap-in - services.msc) you will need to create your service using something like Remoting, Webservices or most ideally as gimel mentioned WCF.