Windows Service that detects domain logons
-
I want to write a Windows Service application that will detect and then perform some tasks whenever a client logs on to the domain. This service will be running on a server with Active Directory. Can someone point me to the right set of .NET (C#) classes or methods that I would need to use for detecting a domain logon event?
-
I want to write a Windows Service application that will detect and then perform some tasks whenever a client logs on to the domain. This service will be running on a server with Active Directory. Can someone point me to the right set of .NET (C#) classes or methods that I would need to use for detecting a domain logon event?
The concept your describing is a Logon Script. It runs whenever a user logs on. You can write them in any script language, JScript, VBScript, .NET Script, ... RageInTheMachine9532 "...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
-
The concept your describing is a Logon Script. It runs whenever a user logs on. You can write them in any script language, JScript, VBScript, .NET Script, ... RageInTheMachine9532 "...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
Actually, I initially did try to use logon scripts. However, logon scripts always run in the context of the client (ie. from the client's point of view). My goal is to write a script or app that can retrieve each client's computer information when they log on, and record that information into a single database located on the server. However, since the script thinks it running on the client machine, it requires the ADO/OBDC/OLE stuff installed on the client to perform the data access tasks. This is not practical in a network with many client computers. So, after that I tried to do a workaround. That is, instead of making that logon script connect to the database directly, the script will spawn a new process ON THE SERVER (this process is now definitely running from the server's point of view). This requires the data access software to only be installed on the server. This process running on the server will now connect back TO THE CLIENT, uses WMI to obtain client's system info, and then write the info onto the database on the server. The concept is good, but I ran into a bunch of security issues. Connecting back and forth like this makes the network think that there are THREE computers involved (but there actually only two). When making connections among 3 or more computers, the delegation of tasks is involved. Delegation require more special permissions and authority, and the configuration is hard for me. Sadly, I never got it to work. http://www.mcse.ms/message289939.html http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wmisdk/wmi/connecting\_to\_a\_3rd\_computer-delegation.asp So, I have now decided to create a Windows (NT) Service, and avoid logon scripts. The service will run on the server and hopefully have a way to trap and handle all logon events by clients. So when a client logs on, the service can connect to it, obtain system info, and then write it to the database. This avoids making so many back and forth connections, and thus reduces security complication issues. OK, so now I'm trying to create such a service using C#.NET. Which classes should I use that can provide with such logon event trapping methods?
-
Actually, I initially did try to use logon scripts. However, logon scripts always run in the context of the client (ie. from the client's point of view). My goal is to write a script or app that can retrieve each client's computer information when they log on, and record that information into a single database located on the server. However, since the script thinks it running on the client machine, it requires the ADO/OBDC/OLE stuff installed on the client to perform the data access tasks. This is not practical in a network with many client computers. So, after that I tried to do a workaround. That is, instead of making that logon script connect to the database directly, the script will spawn a new process ON THE SERVER (this process is now definitely running from the server's point of view). This requires the data access software to only be installed on the server. This process running on the server will now connect back TO THE CLIENT, uses WMI to obtain client's system info, and then write the info onto the database on the server. The concept is good, but I ran into a bunch of security issues. Connecting back and forth like this makes the network think that there are THREE computers involved (but there actually only two). When making connections among 3 or more computers, the delegation of tasks is involved. Delegation require more special permissions and authority, and the configuration is hard for me. Sadly, I never got it to work. http://www.mcse.ms/message289939.html http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wmisdk/wmi/connecting\_to\_a\_3rd\_computer-delegation.asp So, I have now decided to create a Windows (NT) Service, and avoid logon scripts. The service will run on the server and hopefully have a way to trap and handle all logon events by clients. So when a client logs on, the service can connect to it, obtain system info, and then write it to the database. This avoids making so many back and forth connections, and thus reduces security complication issues. OK, so now I'm trying to create such a service using C#.NET. Which classes should I use that can provide with such logon event trapping methods?
Well, the problem with running this on the server and having WMI connect back to it is now your running an expensive process on the server and using some very expensive resources to connect back to the client. Writing a service to do this will not be any easier since you'll be running into the exact same security and connection problems. The only difference between a normal Windows app and a Service is a Service runs on a hidden desktop. I've been in the situation your in now. Believe me, you do NOT want to be spawning a process like this on the server. You'll have one of these running for each login that occurs, and .NET Framework apps are a little heavy on the memory. The less you have running on the server, the better off you'll be. This is better accomplished with a client side utility that inventories everything you need on the client, running on the client, out of the login script. Then it writes a record to some file file on the server. I used a straight .CSV text file. Then, once a night, when the demand for server resources is lowest, the server kicks off a process that parsed up the .CSV file and dumps all the data to an SQL server database. Actually, when I did it, I used a dedicated process on the SQL Server that went to each domain controller and picked up a copy of the file, deleted the original, and then parsed it locally on the SQL server. I kicked my process off once a night, but you could kick it off at any interval you want. RageInTheMachine9532 "...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
-
Well, the problem with running this on the server and having WMI connect back to it is now your running an expensive process on the server and using some very expensive resources to connect back to the client. Writing a service to do this will not be any easier since you'll be running into the exact same security and connection problems. The only difference between a normal Windows app and a Service is a Service runs on a hidden desktop. I've been in the situation your in now. Believe me, you do NOT want to be spawning a process like this on the server. You'll have one of these running for each login that occurs, and .NET Framework apps are a little heavy on the memory. The less you have running on the server, the better off you'll be. This is better accomplished with a client side utility that inventories everything you need on the client, running on the client, out of the login script. Then it writes a record to some file file on the server. I used a straight .CSV text file. Then, once a night, when the demand for server resources is lowest, the server kicks off a process that parsed up the .CSV file and dumps all the data to an SQL server database. Actually, when I did it, I used a dedicated process on the SQL Server that went to each domain controller and picked up a copy of the file, deleted the original, and then parsed it locally on the SQL server. I kicked my process off once a night, but you could kick it off at any interval you want. RageInTheMachine9532 "...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
Yes, I absolutely agree with you that spawning a process on the server for each logon event is very resource-consuming. However, if I make a Windows Service, then won't it be running on the server as just one copy? (ie. there's only one MySQL service running all the time). The service just sits there quietly in the background and will perform some desired task only when it detects a client logging on. I dont think multiple copies of the service are made, one for each logon event. Also, the connection/security issues only gets complicated (for me) when I have to make many back and forth connections. If it's just the service application connecting the a client, then I believe it should be relatively easy. I also did think about the idea of having each client write its own info to some file on the server. However, if many clients happen to log on at about the same time, then would it be a problem if they all try to access the same file on the server? Now, if I let each client write its info to a separate file, then it would avoid this problem. However, the problem now is that there will be too many I/O operations over a short period of time. That will make it slow. Using the files method, initially I was thinking of writing just a simple application for the server's desktop that would then read the file (or all the files) and dump the info to a database. To get an updated database, the server administrator would just have to double click the app whenever he/she wants. But now, I like your idea of having a process that automatically "kicks off" at any certain time of day. How can I make such an application that will run at any desired time?
-
Yes, I absolutely agree with you that spawning a process on the server for each logon event is very resource-consuming. However, if I make a Windows Service, then won't it be running on the server as just one copy? (ie. there's only one MySQL service running all the time). The service just sits there quietly in the background and will perform some desired task only when it detects a client logging on. I dont think multiple copies of the service are made, one for each logon event. Also, the connection/security issues only gets complicated (for me) when I have to make many back and forth connections. If it's just the service application connecting the a client, then I believe it should be relatively easy. I also did think about the idea of having each client write its own info to some file on the server. However, if many clients happen to log on at about the same time, then would it be a problem if they all try to access the same file on the server? Now, if I let each client write its info to a separate file, then it would avoid this problem. However, the problem now is that there will be too many I/O operations over a short period of time. That will make it slow. Using the files method, initially I was thinking of writing just a simple application for the server's desktop that would then read the file (or all the files) and dump the info to a database. To get an updated database, the server administrator would just have to double click the app whenever he/she wants. But now, I like your idea of having a process that automatically "kicks off" at any certain time of day. How can I make such an application that will run at any desired time?
lnong wrote: However, if I make a Windows Service, then won't it be running on the server as just one copy? True, but now you'll have all of your logoons running through a single service on the machine collecting data in a time-consuming fashion (remote WMI). Unless you make you service multi-threaded you'll bottleneck client logons. Now, your spawning multiple threads to do the same job multiple processes would have done. In reality, there's no difference. No, file concurrancy is not a problem. If you have the client inventory app running out of the login script, the client will launch the app just like any other Windows process and the login script will continue on it's merry way. The inventory app will be running while the client finishes it's logon sequence. When it comes to writing the record to the file, you open the file as Deny Share Read and Deny Share Write. If the client can't get the opened, it waits a random number of milliseconds and tries again. In may version, I had a 10 retry limit with a maximum random delay of 2000 milliseconds. The number of file I/O operations was low. I tested this mthod, before I deployed it of course, with 10 machines running 10 processes each, trying to write to the same file with the mentioned scheme. Not one hiccupp or failure was ever experienced over a one hour period with over 2,000,000 records and not one record was lost. How can you make an app that launches at a specific time? Easy, just write it as a console app and use the Scheduled Tasks control panel app to run it. The app doesn't have to worry about a timer or the current system time at all. At the end of the record collection, it quits on it own. RageInTheMachine9532 "...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome