Well in my case its VMware host’s deployed from an template server, so I just installed the service on these. We how ever use these images for many different installations, and not all go into the same domain, so the template is not member of a domain, and when we deploy new machines from the template the OSCustomizationSpec doesn’t instruct the machine to join a domain. Wonderful, means my service have to run as a built in account. I choose Local System. Mostly to address some permissions issue I might blog about later. One of the things that gave me trouble after this, is the fact that, once VMware is done with sysprep the machine, it keeps the auto generated name ( like WIN-QJ61PJL91J1 ) for a few minutes, before the new name takes effect. If your using the computer name to uniquely identify the machine, that will give some headaches.
Once the computer name thing is handled you can now safely add the computer to what ever domain you want spawning a process like this
"netdom join " & My.Computer.Name.ToUpper & " /Domain:" & domainDomain & " /userD:" & domainUsername & " /passwordD:" & domainPassword & " /Reboot:02"
So now comes the big question. Do you now reinstall your self with domain credentials or do you start going down the road I did ? if you don’t need console access the first is defiantly easy. The latter can be challenging, but rewarding in the end. My first approach went something along the line of adding AutoAdminLogon under Winlogon and then adding my services to the “RUN” key. Once the console application had started I would move the RUN key from HKLM to HCKU so the service wouldn’t start spawning on Remote Desktop/Citrix servers. but it doesn’t take long until you get tiered of having all your machine auto logging in. Besides even if you use LsaStorePrivateData to store the password so it isn't directly readable in the registry its still not that secure, so you properly want to get rid of that at some point. ( I will gladly post the code for storing “auto login password” in the LSA store if anyone needs that )
So, I was struggling with all that, and at the same time being more and more annoyed about not being able to do some good trouble shooting for installing applications, so I started going down the road of spawning a process at console. Go on, Google it … you will find tons of post about how to do it, and equally many posts stating you cant do it in Vista, Windows 8 and windows 2008. Well you can … You need to run as “local system” and enable “interact with desktop” .. no, you don’t need that either ….
First, there are many different ways in .NET you can spawn a process ( hello System.Diagnostics.Process.Start ) . There's also lots fun ways to get old really fast, trying to call windows API’s ( CreateProcess, CreateProcessWithLogon, CreateProcessAsUser is bound to make you scream like a little girl ) but I finally fell in love with CreateProcessAsUser. I found some very nice code to handle calling processes and controlling stdOutput, stdError and stdInput ( look at http://www.vbforums.com/showthread.php?p=3821573 ). I modified the code to allow me to either run a process as my self, or pass in a Token for another users process and spawn it as a child of that and STILL get the input/output. Very nice stuff. So what I do now is I just query all explorer processes, gets the owner, check the permissions for the owner and if the owner have the permissions needed I start it at he’s console. That way I can logon remotely via RDP and see what's going on. If no user is logged on (either at console or RDP with the prober permissions ) I add AutoLogin information, restart the machine, then remove the autologin information again once I see an explore with the proper permissions.
Ingen kommentarer:
Send en kommentar