Well lately i have been working on trying to get a good way to view what is happening with the hives when not at home. So here is the first hive cam that we have looking at the one ‘Normal’ hive. There is a new image every 5 minutes. If you click on the link you should get a high resolution image. (May have been taken a few seconds earlier.)

Version 2.6 of the PDT has been released with some updated features. You can find the blog post for its release here.

When ever Rob releases a new version the first thing I do is update my XLS with the list of variables that are available so I can see what has changed and what new options now have. Here is a copy of my XLS.

There are 3 tabs one that lists all roles that are found in the workflow.xml, One that lists all the variables that are found in the workflow.xml and one that lists variables that are used in the VMCreator.ps1 file.

Today I was working on a newly deployed Operations Manager system and there were a number of SQL servers that were not getting monitored due to default permissions that are implemented in the SQL management pack.

After a quick discussion with the client it was decided to add add the LocalSystem account back in to the Sysadmin group so it would work closer to the way that SQL 2008 / 2005 did.

Quick hunt around the internet and found some code that was posted David Brabant and thought that this looked like a good starting point. In the case that I have the account exists and it just needs to be added in to the group.

There is a great patching script that is hosted on codeplex for patching wim / vhd. I have made some minor updates to it so it can also patch VHDx and will just run with windows 8 and require no additional components.

To patch a VHDX of 2012 R2 and only download what is needed
for that os.

So there is an offline VM servicing tool for OS level
Patches. There are some for the 2008R2 / Windows 2012 that need to have
the image updated manually as they depend on other patches that have not been
installed yet.

So best is to run this over your image then power it up and
sysprep it then shut it down and re-run it and all updates should be installed.

I would be expecting to get the following message for each
image / patch run.

It is because there are updates that are listed that wont
install due to patch requirements. (Requires cluster J or DC role etc..)

Today I had a situation where I wanted to connect using eventvwr to a remote machine. I had been able to use PowerShell to connect to the remote machine but wanted the Event Viewer Gui for some quick filtering.

So opened up Event Viewer and entered my remote machine name and waited. After about 30 seconds the following error came back.

Ok so by the looks of things we need to enable some firewall rules .

First thing is to get a list of the firewall rule groups that are on the remote server.

I am often rebuilding my lab environment and finding that I want to run windows update on all of the guest vms in it. This in its own is not a problem but I don’t want to set up a WSUS server or wait for all the clients to do the normal Windows Update check-in Cycle.

This module works great but it had a few things missing for what I wanted.

If updates were needed after the first boot you had to manually run the module / script again

If you don’t have Microsoft Update enabled you are not able to patch anything other than core OS updates.

If you don’t have Use Include Recommended there would still be updates that could be missed.

Please don’t misunderstand me there is nothing wrong with the module itself but, for my list of requirements the module would not meet everything that I wanted to do. So out came some more PowerShell and in a few hours all my requirements have been met.

So first issue was to enable the Microsoft Update module remotely. This one is the easiest of the list above to fix. There is a COM object for Microsoft Update that allows you to enable Microsoft Update programmatically. For me the best way to update this is to just PowerShell remote in to the target machine and update the service.

So now we can remotely enable Microsoft Update service on any machine that we can remotely execute PowerShell on. Task two done.

Ok working on the list of tasks the 3rd was the 2nd easiest to get going. This one took a bit of creative thinking but no big deal. I was able to use the base of the code above and switching the COM object to Microsoft.Update.AutoUpdate you can enable the includeRecommendedUpdates.

This time I got a whole bunch of red hhmmm this works on local machine but not on remote.

Time to open up my search engine and try to find out what is going on. Turns out that while the code is sound it seems that Microsoft has not enabled remote access to the Microsoft.update.autoupdate objects. (I knew that you could not remotely call windows update but I didn’t think about changing settings having the same issue.)

So the best way to get around this is to enable the setting using a scheduled task. The good news about doing this is the Invoke-WUInstall command from PSWindowsUpdate already does this so all that we need to do is add this script into the script that Invoke-WUInstall calls. In my case I wanted to be able to set IncludeRecommended by variable.

Now when we call the Invoke-WUinstall it will create a remote scheduled task on the computer. One of the commands that it will execute will be to enable Recommended updates.

Ok so two parts of the script are done. Now for the most fun one. I want to have the scheduled task run multiple times on the remote machine until either the number of times that I have set have run or all updates are applied.

The first step is to add in a trigger to the job that PSWindowsUpdate created. As the machines that I am wanting to update could be running anything back to windows 2008 R2 and will most likely have PowerShell 3.0 installed I could only use the scheduler Com components to update the task.

Instead of having to manually copy the script out to all of the targeted machines, I wanted to include it in my original script with the ability to write it out to my target machine, if required. The best way to do that is to use a here string in PowerShell. When you are doing this you will just need make to sure that if you want to add in variables that you add the ` in front of the $ otherwise PowerShell will put the values for the variables in at run time and not write them out as you may want . I have only included a small snippet of the script here string showing that I added in some parameters and also checking if the destination folder that the script is to be written in exists.

So that was task one done. At this stage it is now complete. I have a script that checks and enables Windows Update, Auto Updates, Recommended updates on remote machines allowing them to reboot a number of times and re-run updates until they are fully patched.