Our Active Directory lead recently complained to me that he didn’t have a good way to compare Group Policy Objects. I had already written the Group Policy Reporter, which exports GPOs to HTML files, and it occurred to me that comparing two HTML files would be pretty easy. But my experiments with Compare-Object led to some pretty ugly results. I frequently compare documents using MS Word, and I decided to use Word to do the comparison of the files.
The new script, GPOCompare.ps1, makes a list of your GPOs and displays that list using Out-GridView. After you select two GPOs, you are asked which is the “original” (earlier) GPO for Word to use as the original document. The HTML reports are created, then a comparison is made using Word. This script requires PowerShell 3, The Group Policy Management Console, and Word installed.
The Word COM object is not fun to work with in PowerShell. In particular, you cannot use $Null for some of the unused parameters, and note that many must be explicit references, example [REF]$True.
I am a member of a terrific IT User group, Carolina IT Professional Group. This group is focused on educating its members, and giving back to the community. But what really keeps people to the end are the terrific door prizes. At the July meeting, I won a copy of Server 2012 R2. I had been running Server 2008 on my home network and decided that it was time to upgrade. The first lesson is this: Server 2008 is the Vista codebase, and Server 2012 R2 is the Windows 8.1 codebase. You can’t upgrade from Vista to 8.1, nor can you upgrade to 2012 R2 from 2008.
A fresh OS install on my old domain controller — and fresh drives – was appropriate. I downloaded an evaluation copy of Server 2012 R2 and installed it on one of my more capable workstations. I installed the appropriate roles, moving AD and DNS over to it. No problem. After migrating the home directories onto a 2TB drive, I went on and installed a boot disk to replace the aging mirrored 500GB drives in the old DC.
I then installed my licensed copy of 2012 R2, and went looking for my home directories. To make a long story short, lesson two is remembering about the necessity of importing “foreign drives” when you move a disk between Windows installs. Somehow along the way the security for the home drive folders got hosed, and I took a significant amount of time resetting the ACLs.
I have installed AD and DNS on my permanent DC, and am waiting for things to calm down before I remove those roles from the temporary DC.
The last lesson is this: Server 2012 R2 has the same idiot UI as 8 and 8.1. I was happy to find that Classic Shell works just fine at restoring a traditional start menu to Server 2012 R2. For my thoughts on 8.1 and Classic Shell, visit this blog post.
Update: I have installed the “Windows Server Essentials Experience” which allows me to remotely backup all my workstations. For more information, visit http://technet.microsoft.com/en-us/library/dn281793.aspx.
This script has been updated, and will be featured in a new Scripting Guy Article written by yours truly. A link to that article and the new script will be available soon. If you can’t wait, drop me a note and I will email it to you.
Looking for a script to run Windows Update remotely? WindowsUpdate.hta version 3.1 is an HTML application which allows you to connect to a remote machine, determine what patches it requires from Windows Update, and install the patches. You can schedule a reboot time. This version allows you to look at he Windows Update log, and the log created by the program itself. There is a button to allow you to change the update source to windowsupdate.com, which is helpful in places where WSUS or SUP is not working properly. You can install all security patches, or select patches individually.
HTA files are best run from your local drive. Version 3.0 was released in 2011, version 3.1 only changes the background color to blue. The transition color method I had used for the background is no longer supported in IE, and the program appeared to be broken.
Change _hta.txt extension to .HTA.
Although I have spent most of my time recently writing PowerShell code, I still get requests from the field for vbscripts. The security model differences make it more time consuming to explain how to run a PowerShell script than vbscript’s “double click this”. DisablePCsFromList.vbs is an updated version of a 2006 vbscript which reads a text file with a list of computer accounts, and deletes the list. A log file is written to the user desktop.
I was reviewing my blog stats today and found a link from a site in UK to my version of ScriptoMatic.hta. I have upgraded my home laptop to 8.1, and decided to see whether it still works (it does). If you launch the “fixed” ScriptoMatic as an ordinary user, it takes a very long time to load. But after it did, I found that it worked just fine. I began reviewing the WMI classes listed, and found one that I had not noticed before, Win32_ReliablityRecords. This class, introduced in Windows 7, gives you a list of failed installs, system hangs, and application crashes in an easy to read format.
Scriptomatic created a nice vbScript to enumerate the class. I coded Get-ReliablityRecords.ps1 in PowerShell with one-third the lines including comments. It has only basic parameters. You may choose a remote computer and a limit on the records returned.
I frequently get a request to delete a list of computers in my AD domain. Often the list is in an email. Delete-PCListFromClip.ps1 is a short script which reads the content of the clipboard, then sends the list to Out-Gridview for review. You may then select the computer names for deletions. PowerShell 3.0 and the ActiveDirectory module are required.