This week’s PowerShell tip is actual inspired by one of the most useful VBScripts that I have ever used in managing a network. Let’s just call it a massive system reboot. Remember way back when…. When you had to physically visit each of your servers for updates. For me, it turned into a two week trip every 3 months. It was way cool at first. Especially for trips to California (I live in Indiana. Anything outside the Midwest is cool.) This started turning into both a time and budget drain. In Windows 2000, we had the ability to remote desktop in. Now, I was working two 12 hour days, 4 weekends a year. The problem was the reboot. I had to reboot the servers. I would mostly just work on other things while the servers were updating and then reboot when necessary. Of course there was the occasional shut down. Then I would have to call someone on site to drive into work on a weekend to press the power button.
Once I started using a script to reboot servers for me, my weekend time went to zero. Also, the accidental shut downs were non-existent. That same VBScript still works on Server 2008. But this is the age of PowerShell. So I took this opportunity to rewrite the script in PowerShell. Let’s take a look at some of the key parts.
We are going to use the WMI object of W32_OperatingSystem. Let’s enumerate the methods in
W32_OperatingSystem in PowerShell.
This first step creates an instance of the W32_OperatingSystem object and places it in a variable called $WinShut.
• $WinShut = Get-WmiObject win32_OperatingSystem
We are now going to enumerate the methods that are available to us. Remember, methods are actions, properties are data.
• $WinShut | Get-Member –membertype method
TypeName: System.Management.ManagementObject#root\cimv2\Win32_OperatingSystem
Name MemberType Definition
---- ---------- ----------
Reboot Method System.Management.ManagementBaseObject Reboot()
SetDateTime Method System.Management.ManagementBaseObject
Shutdown Method System.Management.ManagementBaseObject Shutdown()
Win32Shutdown Method System.Management.ManagementBaseObject Win32ShutdownTracker
You should have gotten output similar to what is above. We are interested in Win32Shutdown.
Win32Shutdown has different values that we can assign to it:
• 0 - Log Off
• 4 - Forced Log Off
• 1 - Shutdown
• 5 - Forced Shutdown
• 2 - Reboot
• 6 - Forced Reboot
• 8 - Power Off
• 12 - Forced Power Off
Let’s give it a try. We can do this from scratch or use the variable that we created earlier. Just to warn you, DON’T DO THIS ON THE COMPUTER YOU ARE READING THIS BLOG ON. Do it on a test machine.
• $WinShut.Win32Shutdown(0)
What about a remote logoff or shutdown?
We need to open PowerShell with an account that has administrative credentials.
• Click Start and type CMD.
• Press Enter.
• Type runas /env /user:administrator@domain.local “powershell.exe”
Name MemberType Definition
---- ---------- ----------
Reboot Method System.Management.ManagementBaseObject Reboot()
SetDateTime Method System.Management.ManagementBaseObject
Shutdown Method System.Management.ManagementBaseObject Shutdown()
Win32Shutdown Method System.Management.ManagementBaseObject Win32ShutdownTracker
You should have gotten output similar to what is above. We are interested in Win32Shutdown.
Win32Shutdown has different values that we can assign to it:
• 0 - Log Off
• 4 - Forced Log Off
• 1 - Shutdown
• 5 - Forced Shutdown
• 2 - Reboot
• 6 - Forced Reboot
• 8 - Power Off
• 12 - Forced Power Off
Let’s give it a try. We can do this from scratch or use the variable that we created earlier. Just to warn you, DON’T DO THIS ON THE COMPUTER YOU ARE READING THIS BLOG ON. Do it on a test machine.
• $WinShut.Win32Shutdown(0)
What about a remote logoff or shutdown?
We need to open PowerShell with an account that has administrative credentials.
• Click Start and type CMD.
• Press Enter.
• Type runas /env /user:administrator@domain.local “powershell.exe”
Of course replace administrator@domain.local with the UPN of an account with administrative rights.
PowerShell v2 has some nice remote features built into it. But first, let’s prep your Windows Server 2008 R2 and Windows 7 machines.
• Click Start --> Control Panel
• Click System and Security
• Click Allow a program through Windows Firewall.
• Check:
o File and Printer Sharing
o Windows Management Instrumentation(WMI)
• Click OK
• Click System and Security
• Click Allow a program through Windows Firewall.
• Check:
o File and Printer Sharing
o Windows Management Instrumentation(WMI)
• Click OK
This is good for one or two computers. What about 500? This is when Group Policy comes into play.
• Open Group Policy Management
• Open or create a Group Policy to manage your firewall on the clients that you are going to run this script against.
• Click Computer Configuration --> Policies --> Windows Settings --> Windows Firewall with Advanced Security --> Inbound Rules.
• Right Click Inbound Rules and Click New Rule.
• Click Predefined.
• In the Drop down box click File and Printer Sharing
• Click Next
• Click Next
• Click Finish
• Create a new rule for Windows Management Instrumentation(WMI) also.
• Open or create a Group Policy to manage your firewall on the clients that you are going to run this script against.
• Click Computer Configuration --> Policies --> Windows Settings --> Windows Firewall with Advanced Security --> Inbound Rules.
• Right Click Inbound Rules and Click New Rule.
• Click Predefined.
• In the Drop down box click File and Printer Sharing
• Click Next
• Click Next
• Click Finish
• Create a new rule for Windows Management Instrumentation(WMI) also.
Remember that the policy must refresh on the clients before you can proceed.
OK, now let’s connect with our clients and log them off.
OK, now let’s connect with our clients and log them off.
• $WinShut = gwmi Win32_OperatingSystem –computer computername.
In this line, we used the alias gwmi to shorten the typing. Gwmi is short for Get-WMIObject. Replace computername with the name of the client that you want to reboot
• $WinShut.Win32Shutdown(6)
Once you press enter, the client will reboot. Again, replace the parameter of 6 with the desired outcome.
Next Tuesday, we will look at how to restart multiple clients in Part II of this article.
Next Tuesday, we will look at how to restart multiple clients in Part II of this article.
Comments