Use PowerShell and Group Policy for Your Logon Script
Summary: Microsoft Scripting Guy Ed Wilson discusses the pros and the cons of using Windows PowerShell for logon Scripts.
Hey, Scripting Guy! In the past, I worked at a company that had an impressive logon script. It was written in VBScript and consumed more than 5,000 lines of code – I am not joking here, it was more than 5,000 lines long. I no longer work for that company, but I am certain that if it were converted to Windows PowerShell, it would not be nearly that long. My question is this: do people use Windows PowerShell for logon scripts? If so, how is it done?
— YT
Hello YT, Microsoft Scripting Guy Ed Wilson here. I do not know about you, but I am slowly returning to “work mode” after a decent amount of time away. When the Scripting Wife and I went to Greenville, South Carolina for an overnighter, I did not even pack my laptop. Later that night I began to have withdrawal symptoms, and I specifically asked her, “Do you even remember the last time we have been away without a computer?” To solve the mystery, no; neither the Scripting Wife nor I remembered the last time we were away from home without a laptop.
On reflection, the last time I left home without carrying a laptop might be back when I was a network administrator, prior to laptops becoming commercially available. In fact, back in the days when I was a network administrator, login scripts were all the rage. Everyone who was anyone would spend weeks and weeks crafting the perfect login script. Nevertheless, to be honest, login scripts back then were the primary means of user management. If one wanted to deploy software to a user, one used a login script. If one wanted to map drives, or printers for a user, again the login script was the mechanism to utilize. In fact, I even had a command that I used to synchronize the time on all the workstations with the domain controller. None of those things is required nowadays. In many cases, a modern network can survive without a logon script. The tool that replaces the old-fashioned logon script is Group Policy.
With Group Policy it is easy to map drives and printers by creating a new Group Policy Object. This is seen in the following figure.
One of the cool things about using a logon script to map drives is that I can use WMI to determine if the script is running on a Server (for example when I need to log onto a server to make changes I do not need a logon script running and mapping a bunch of drives.) Using Group Policy I can also use WMI to perform this filtering. I created a WMI Filter to filter out only Workstations. This is an important technique for Scripters to learn (even if it is a Group Policy thing) and I discuss it in detail in the Using Group Policy to Deploy a Windows PowerShell Logon Script post.
After the drive mappings have been accomplished the Drive Maps screen appears as shown in the following figure.
If you are going to be using Windows PowerShell for logon scripts, they will be assigned via Group Policy. In this case, I would use a standard GPO (Group Policy Object) to perform as many configuration tasks as can be accomplished via Group Policy. Then I would use WMI filtering to perform all the filtering that needs to be performed. Anything else that needs to be done would then be relegated to the Windows PowerShell logon script. (Just as a FYI, I prefer to create single purpose GPO’s instead of massive “configure everything” GPO’s. This makes it easier to enable or to disable as required. In addition, it makes them easier to troubleshoot. Because my GPO’s tend to be single purpose, I always turn off processing of the unused portion of the GPO.
Because I use GPO’s to perform most of the legacy configuration duties that were previously relegated to logon scripts, you may ask what I use logon scripts to accomplish nowadays. The answer is that my “new” logon scripts tend to be special purpose. For example, I like to use Group Policy to create a folder off of the root and to populate it with utility scripts. This is easily accomplished by using the Files portion of the GPO and the Folder portion of the GPO respectively. In the past, I utilized a logon script to create the folder and to populate it with the scripts. One of my favorite things to do is to create a Scripting event log. This is something that cannot be accomplished via Group Policy, and therefore it is a great candidate for a logon script. When I wrote the Weekend Scripter article that collects process snapshots during the login process, I designed the script so that I could use a logon script to call the script. Once again, this is a task that could not be performed with Group Policy, and is a perfect candidate for a Windows PowerShell logon script.
If you are not using Group Policy, you can still use a Windows PowerShell script in a logon script. To do this, you modify your logon.bat file (or whatever it happens to be called) and have it call your Windows PowerShell script. Make sure the script is located on an accessible file share, and that is it. You may want to use the bypass option. An example of this command is seen here.
powershell -executionpolicy bypass -file \\DC1\scripts\myLoginScript.ps1
To summarize, in general, many well managed and well maintained networks get by without using a logon script. This is because most, if not all, of the traditional duties of logon scripts have been co-opted by Group Policy. The advantages of Group Policy are that: it is easy to use, easy to maintain, and easy to back out configuration changes that it performs. I use logon scripts only to perform tasks that Group Policy does not perform.
YT, that is all there is to using Windows PowerShell and logon scripts. Join us tomorrow for Quick Hits Friday.
I invite you to follow me on Twitter or Facebook. If you have any questions, send email to me at scripter@microsoft.com or post them on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.
Ed Wilson, Microsoft Scripting Guy
Light
Dark
0 comments