Munnar was the only location, where we were scheduled to stay for two nights means full one day for the place as the day next, we were to leave as early as possible to reach Bangalore in time.

When we woke up, it was raining but nevertheless, we got ready and then by 7.30 AM, we would have been on nearby restaurant for a heavy breakfast. After which we started driving after 8.30 AM. This time we had hired a guide to drive with us and show us around @ 500Rs.

It continued to rain though we had hopes that it would settle till the time we reach to the viewpoints and luckily it happened that way.

We all waited for morning to have more fun on beach, elders and kids alike. The first job in morning to get ready after bath etc and head to beach with sand castle tools.

We must have reached the beach by 7 AM. The lighthouse wasn’t gonna open before 10AM which means it wouldn’t cut into our schedule. It was all about the time on beach now and mild showers were worrying us.

What better feeling than to watch the sunrise at the last end of your country with 360 degree of sea view around and that too under a cloudy and less warm weather. Would admit we wouldn’t have preferred cloudy but a clear sky but every weather has its own texture and should be taken as such.

Morning started with mild showers and we had to take umbrellas from the hotel. The excitement to walk towards the end of the country boundary was just something else.

Changing colors with each passing minute, the place is worth spending the entire day just sitting on that stone bridge.

The view, the showers, people trying to sell sea shells and even tea vendors doing ferry on that small but not that crowded place, if it wasn’t about rains and specially kids, then we would have stayed much more longer there but then guarding kids on that place where both side it was heavy waves, our mind was asking us to move from there.

Finally this was the day for which kids been waiting for. Sand castles on sea beach, but they had to wait little more as elders needed to visit Rameshwaram temple. No photos as cameras were not allowed in temples. We woke up early, taken bath, did Manidarshan, but going for “22 Kund snan” was kind of tough with kids around so we chosen the short route. By some 8.15 AM, we would have been free to drive again after checking out from hotel.

We reached Danushkodi by 9 AM where we were stopped some 5-6 kms before by a check-post in name of “Road construction” which meant we weren’t allowed to go further at this weather at least. An impromptu parking spot it was from where pvt ferries used to take people to a certain point (Not the last end) on a cost from off-road route. It might look like just a line in maps, but including the shores, its around 500 mtr wide place which stretches around 7kms from north to south. It shares ONLY land border between Sri Lanka and India which is one of the smallest in world at 45 mtrs in length. (of course we didn’t made it to that point).

This place is actually called as “Ghost Town” due to a tragedy back on 22 December, 1964 which wiped out roughly 1800 people including those 115 passengers on Pamban-Dhanushkodi passenger train. After that railways station was wiped out and the train never began its operations. A commission looked into possibility of new rail in 2010 and last year a road was constructed till this point.

Anyway… we went into history of the place… let’s come back to travelogue…

The story is about the longest break I might have taken in last decade or so. The story is about a trip ranging close to 5700 kms, out of which 2200 kms was on roads driven by me in a car which was not my sweetheart Vista. The story is about a trip which gave first glimpses of sea to my kiddo. The story is about lush green mountains of Munnar. The story is about three families with four kids having fun together.

This is just glimpse, a lot more to come from the repository of more than 20Gb of raw photos detailing moments from six individuals and four kids.

I am back again with just another write-up on WSUS in a very short time. Last time we talked about Reporting and Cleanup, this time its more into troubleshooting, which often requires one to find particular updates and nuke them out.

Yes! We are talking about those pesky Event IDs 364, which often mention about certain cab files and we System Admin bang their heads on walls to find out that which particular updates they belong to.

Let me give you an easy permanent way out via a Custom PowerShell module named PoshWSUS.

How to use that?

Just download the module, extract the folder named PoshWSUS and copy the same to PowerShell module location for your WSUS Server (I am assuming you have Windows 2008 or Windows 2012 though it works for older ones as well).

Ok. So where is this PowerShell Module Location?

Usually it is C:\Windows\System32\WindowsPowerShell\v1.0\Modules but to know for sure, can open PowerShell prompt and Type $PSHome, which should give you C:\Windows\System32\WindowsPowerShell\v1.0

Installed the module, now what to do?

You can make use of the below code:

Import-Module PoshWSUS
Connect-PoshWSUSServer –WsusServer -port 8530
# In case you got some Windows 2003 machine which is connect over port 80 in place of 8530 then uncomment the below line and comment the one above this comment.
# Connect-PoshWSUSServer –WsusServer -port 80
Get-PoshWSUSUpdate | Get-PoshWSUSUpdateFile | export-csv -notype $env:userprofile\desktop\WSUSFiles.csv

This would give you all the update names, their corresponding files, their actual disk locations and then you can easily find out, which was the particular update, which is causing you Event ID 364. Once you know that its your choice that how to deal with that update, decline, clean and approve, download again or whatever you prefer.

All well? Nope! There might be still a trouble

There is a tricky scenario as well like the one I faced once and that is Local Update Publisher. Microsoft gives the way that one can push certain non-Microsoft updates via WSUS solution after packaging it in a certain format. Looks good but may be a huge trouble when things go wrong. Updates pushed by LUP don’t show up in GUI of WSUS console, so it gets tricky to decline or clean them out. PowerShell comes handy in such scenario as by that we can find updates by keywords and then decline or delete them. Here goes the code.

[void][reflection.assembly]::LoadWithPartialName("Microsoft.UpdateServices.Administration")
$WSUS = [Microsoft.UpdateServices.Administration.AdminProxy]::getUpdateServer(,$false,8530) # Or port 80
$UpdateScope = New-Object Microsoft.UpdateServices.Administration.UpdateScope
$UpdateScope.ApprovedStates = [Microsoft.UpdateServices.Administration.ApprovedStates]::Any
$updatescope.IncludedInstallationStates = [Microsoft.UpdateServices.Administration.UpdateInstallationStates]::All
$Updates = $WSUS.GetUpdates($UpdateScope)| where-object {$_.title -like "*7-Zip*"}
# In case, the purpose is just to list patches first where title contains 7-zip
$Updates.Title.ToString()
#In case, the purpose is just to decline those patches where 7-zip comes in title, then uncomment the below line
#$Updates.Decline()
# Uncomment the line in case you need to delete the update files and remove patch from DB as well, then uncomment the below line
#$Updates | Foreach-OBject{$WSUS.DeleteUPdate($_.Id.UpdateId.Tostring()); WRITE-host $_.Title.ToString() deleted -ForeGroundColor RED}

Hope this helps. As you know, the health of WSUS can be checked via wsusutil checkhealth and appearance of Event ID 10000 and 10030 confirm that everything is well.

Its been long since I wrote anything on WSUS. As Windows world evolved, many of the troubleshooting steps might be bit out-dated now but WSUS functioning and basics still remain more or less same.

Today I wish to take another aspect of WSUS and talk about WSUS Reporting part and regular clean-up.

WSUS Reporting:

WSUS has a comprehensive reporting system built in and if Report Viewer installed over the server, one can variety of reports, but the same remains limited to a pre-set and also one server only. Let’s think of a scenario, where one might have more than dozens of WSUS servers catering thousands of machines and rather logging over each one or attaching them into one console, we want to have a consolidated report to see if patches getting installed well and also whether team is meeting compliance by install each single patch of (M-1) month.

Now what my PowerShell code does? It bring a report like below in csv format:

This would include how many patches are needed on which machines, when those machines last contacted their respective WSUS servers, what IP and OS do they have and which particular updates are pending on them and those pending updates were released when. Also it tells count of those updates which have been downloaded or pending download or pending reboot of machines to complete the installation.

I believe this pretty much covers what a system admin might need to get an overview of issues and to address them. Apart from this, what the script does is, it creates some more CSV files, one against each WSUS server mentioning that which particular updates were released between the period of 1st day of (M-2) month (if today is March, then we talking about January 1st) and Second Monday of (M-1) month means just one day before Patch Tuesday. Based on this data, one might check if any of the last month patches are missing on any of the servers. I have written a Excel Macro code around that as well but that still needs updating and make compatible for general usage so would post that at some later time.

Also notice, in code, there are two arrays of WSUS servers. Essential difference between the two are the connection lines. One connects over 8530 port while other connects on port 80, there might be SSL and non-SSL options as well, which can get handled by the second attribute passed depending on your scenario.

Once the report task is done, let’s talk about one smaller one. Cleaning of WSUS not relevant files and Computers. WSUS itself provides a one click option for this but again, it doesn’t cater if you want to handle multiple servers at once nor gives you a text report of what happened in one pass. So, here goes the another script to solve that part.

Now this script considers that we are in a SCOM monitored (or may be some other tool) environment means we would get a few tickets when we run the clean-up as clean-up restarts the update service on each WSUS twice and also may trigger high CPU etc. The script stops before each WSUS server and takes a manual input from you while informing you that its going to work on which server and that server should be put into maintenance mode in SCOM before proceeding further. It logs everything into the same directory where the script is. The path can be changed in case needed.

Also if one wants to make it completely automated then read-host lines can be removed and also at the end of code, we can add some lines to ensure that the status of entire activity gets passed over email to relevant personnel.