How to publish a custom screensaver through group policies

     Last week I received a request from one of my customers that wanted to publish the same screensaver on all the Windows 7 user machines in their environment.
     A powerpoint presentation was sent over containing two images that should be displayed on the screensaver and I was asked to test and implement it asap(ofcourse).  So I got started immediately, first looking for software that could convert .pptx or image files to a .scr file. Stumbling upon Ace Pro ScreenSaver Creator, I downloaded it, installed it with 3 or 4 clicks and managed to create a custom .scr in just a few seconds.It was a beautiful screensaver, with custom transition effects and you could even add background music to it so I was happy thinking that the customer will surely be impressed.;
    I tested it on my machine, where I created it in the first place, and it worked beautifully.So I copied it over to the customer's environment and created a new GPO.Under User Configuration > Administrative Templates > Control Panel > Personalization I used the following settings:

Policy	Setting	Option
Enable Screen Saver	Enabled
Force Specific Screen Saver	Enabled	moneyscreen.scr
Password Protect Screen Saver	Enabled
Screen Saver timeout	Enabled	Time set in seconds (120)

   That should do it, right? Well, it didn't work. When I asked one of the users to test she could only see this:

 

   Some more research revealed that custom screensaver creators are actually crap when it comes to creating screensavers for a corporate environment and the only thing that can be used safely is Windows 7's default Photoscreensaver.scr.By default Photoscreensaver.scr uses C:\Users\Public\Pictures\Sample Pictures for it's slideshow.This is done through the EncryptedPIDL key inside HKEY_CURRENT_USER\Software\Microsoft\Windows Photo Viewer\Slideshow\Screensaver which looks like this:

That string, which specifies the path to the pictures folder  C:\Users\Public\Pictures\Sample Pictures is encoded in Base64, without headers.You can modify the screensaver settings on a Windows 7 machine and export the key once you've set the proper path to the pictures folder.But that's too easy and boring.
There is a Windows API that encrypt binary arrays (the PIDL) to Base64 - CryptBinarytoString

Our problem is the inverse for which we can use the CryptStringToBinary API.I found this nice powershell script that does that.We just need to export the Screensaver key and replace the EncryptedPIDL Data with the value returned by the script.In the below example I've set the path value to the following: $MyPath = "\\w2008dc\screen\slides" which is where I've stored my files.

All you need to do next is push out the modified EncryptedPIDL through GPO.For this to happen the best way is to create a new policy and apply it to the users OU.You can filter it out to apply to only a certain group of users and the copy it to other GPOs, modify the pictures path in the screensaver registry settings in case you want to display certain screensavers to certain usergroups.
Edit the newly created policy by going to User Configuration -> Preferences -> Windows Settings -> Registry and adding the key as follows:

 Key path is going to be Software\Microsoft\Windows Photo Viewer\Slideshow\Screensaver under the HKCU hive:

On the same GPO you will the need to apply the following settings in User Configuration > Administrative Templates > Control Panel > Personalization:

Policy	Setting	Option
Enable Screen Saver	Enabled
Force Specific Screen Saver	Enabled	Photoscreensaver.scr
Password Protect Screen Saver	Enabled
Screen Saver timeout	Enabled	Time set in seconds (any time you choose)

If you found better/easier ways to do this please drop a comment.I'm going out for a well deserved pint after I've been struggling to finish this article all week!

How to remove the update to Internet Explorer 9 using SCCM

    Microsoft Security Updates include an upgrade to Internet Explorer 9 - kb982861.

    That sounds reasonable and perfectly cool.Unless you're doing patch management.

Just think about that awkward moment when you realise that your client's web applications can only work with Internet Explorer 8!

Supposedly you went ahead and mass-deployed Windows Security Updates to all  Windows 7 x64 computers and received about 100 phone calls from digruntled users.Aaand it's only noon.

    Not saying that happened to me today but I just happened to think about such a predicament and how to handle it like a sir.Let's presume we have SCCM security privileges, ConfigMgr 2007 handy and a working internet connection.It's all we'll need.

    First thing we need to do is google "uninstall ie9 microsoft fix it" and the first link should take us to the right spot.

    The Microsoft Fix it wizard is actually an MSI we can use to remove IE9 and bring back Internet Explorer 8 to life on all affected user machines.

Just download the MSI called MicrosoftFixit50778.msi from the link and create the package using ConfigMgr 2007.

 
   
   Name the package something relevant like "IE9-Uninstall" and select an accessible share directory for the data source, where we will place our .MSI file.You might want to leave Data Access, Distribution Settings, Reporting and Security as defaults or you can set a high sending priority in your Distribution Settings just to play it safe.Next we will place the .msi file we previously downloaded inside the data source folder.
Once the package is created we need to add the distribution points and program.Right click, add new program and put this in the command line box: msiexec.exe /i MicrosoftFixit50778.msi /qn /norestart.
If we click browse we should get to the data source folder.For program requirements we will select Windows 7 x64 and leave the maximum allowed run time to 120 minutes.

    Environment settings are very important.We should take into account that UAC is enabled on the Windows 7 machines and we need this program to run with administrative priviledges.Let's leave anything else as default at this stage as our work is nearly complete.
    Other thing we need to consider is what happens if the users have Internet Explorer open while our uninstall package is advertised to them.We can test and see what happens but instead of wasting valuable time why don't we make sure that the iexplore.exe process is killed before the uninstaller kicks in?
    You might have noticed that the program contained within our package has an advanced tab with an option called "Run another program first".




   We will use a .vbs script that will kill iexplore.exe and set it to run prior to the uninstaller.The script looks like this:
   strComputer = "."
   Set objWMIService = GetObject _ 
       ("winmgmts:\\" & strComputer & "\root\cimv2")
   Set colProcessList = objWMIService.ExecQuery _    
       ("Select * from Win32_Process Where Name = 'iexplore.exe'")
   For Each objProcess in colProcessList    
   objProcess.Terminate()   
   MsgBox "Internet Explorer 9 will be uninstalled.Please reboot at your_ earliest convenience, no sooner than 5 minutes!"  
   Next


   That's right.The message box reminds the users to reboot as the uninstall script runs with /norestart.They don't want to lose any unsaved work, ofcourse. You can just copy this into a text file and save as KillIE.vbs to the same data source location where the .MSI was saved.We can then create a new package using the same process as for the .msi file but we will need to put cscript KillIE,vbs on the command line box of the program.This new program will also need to run with administrative priviledges so the only setting tab we fiddle with is the environment one, same as above.

Let's now go back to the first program and set the second one we created to run first.

Our packages are setup,  so we can add all affected computers into a collection and advertise this package to it.It should take no more than 5 minutes to remove Internet Explorer 9 and IE8 should be found on the workstations after rebooting.



   Just remember to set at least a mandatory assignment to the advertisement schedule to make sure the packages are pushed out.
   Alternately, if we have one or two users affected we can uninstall IE9 by pasting the following in an elevated command prompt: FORFILES /P %WINDIR%\servicing\Packages /M Microsoft-Windows-InternetExplorer-8*.mum /c "cmd /c echo Uninstalling package @fname && start /w pkgmgr /up:@fname /norestart
   When it's done just restart and voila!

 

The windowscodecs.dll unrecoverable error

This is a nice fix I found the other day.

While messing about in my VMware Workstation 9 lab I came across this when trying to power on some server 2008 r2 machines:

Was it the host OS or was it the virtual machine images that somehow got corrupted? They were linked clones so that was a possibility.

The event viewer on the host wasn't very helpful as it gave no clue and just showed the application pop-up events containing the same error message about windowscodecs.dll.

The funny thing was that after clicking ok repeatedly until my index finger got numb the virtual machines could eventually start.So the "unrecoverable error" was no more than a nuissance really.

The first thing I’ve tried, reverting to older snapshots, didn't bring any joy and brought me great dissapointment as I ran out of ideas.
Clearly the virtual machines were not at fault. I even created a vanilla Server 2008 R2 machine which threw the same error at me when I attempted to power on.

I had no inspiration at the moment and no whiskey around so after reading the VMware Communities Forums and the top 15 Google results about similar issues, I decided to downgrade to VMware Workstation 8.I know... "don't believe everything you read on the internet!"
I usually don't but I find that searching the web can often give me an idea on what to do next or where to start troubleshooting.In this case   searching the web for similar issues helped me decide to wipe the VMware installation and re-install WMware Workstation 9 from scratch. 

The VMware installation cleaner will tidy up the registry keys and system files should you ever decide to start fresh

So I reinstalled VMware Workstation 9 and the dreaded error showed up again when trying to power on virtual machines.I then tried to replace windowscodecs.dll on the virtual machines with the version from the installation ISO.Still no joy.
Finding myself in the brinks of despair i turn to the OS.Why not modify windowscodecs.dll on the host with the one from the ISO?After a simple copy-paste and reboot I started WMware workstation only to stumble across the error message again.

During that moment I found myself struck by inspiration so I started searching for the most recent Microsoft hotfix that replaces windowscodecs.dll which lead me to this.

Needless to say that all my virtual machines started with no issues and my index finger was happy to get away from all those clicks after installing the hotfix.