With Windows Server 2008 having role specific snap-ins installed for each role, if you have to demote a Windows Server 2008 DC thru normal “dcpromo” command. You will notice that the DC specific roles from within the Server Manager will not be uninstalled. Even though the DC has been fully demoted, Active Directory has been uninstalled, the Server has been rebooted but the snap-ins for roles such as AD and DNS are still there (in case your DC was also a DNS). It causes a bit of nuisance as its not as if these snap-ins will serve you like “adminpak” and you could manage AD from other DCs from this member server now. As of course for that you will need the RSAT tools. See the screenshots below to see the problem and error if you try to use the snap-in, and finally see the wizards to remove the lingering roles.
Using PowerShell, you can get a report of patches that are installed on a remote workstation/server. Launch the PowerShell and run the following command where testworkstation is the name of your computer.
Get-WmiObject -Class Win32_QuickFixEngineering -ComputerName testworkstation
If you need to provide another set of credentials for the domain-joined machine you are after, or if you get access-denied error. Use the Get-Credential cmdlet to provide the credentials.
You can see above the default output of the cmdlet, but you can narrow down the results with the following option.
Get-WmiObject -Class Win32_QuickFixEngineering -ComputerName testworkstation | select description,hotfixid,installedon
I would further export it to a CSV for an easier review and analysis with the following export option.
Get-WmiObject -Class Win32_QuickFixEngineering -ComputerName testworkstation | select description,hotfixid,installedon | export-csv c:\Testworkstation_Hotfixes.csv
As you can see that this cmdlet relies on the WMI object class. It is necessary to have the pertinent ports open between the workstation you are running this from to the target. WMI is an entity of shared DCOM ports/services. If there are firewall issues you can’t overcome then perhaps run the PowerShell cmdlets from within the same subnet of your target machine.