Windows Deployment Services Error Code 0xE0000102.

Whilst recently configuring Windows Deployment Services on a Windows Server 2003 R2 Enterprise SP2 system, I noticed the error code 0xE0000102 appear while running through the server configuration. The configuration bombs out and you are left with an unconfigured WDS server.

I think I have this one nailed. It seems that if your system had Windows Server 2003 Service Pack 2 installed before you joined a domain, you will hit this error.

I noticed this in my lab environment, where I commonly build a virtual server template with 2003 R2 SP2. All new servers are cloned from there. Once the clone is created, I join them to a domain if required, so SP2 exists prior to domain joining.

The answer? Remove SP2, reboot, reinstall.

Blocking Adobe Flash Player Automatic Updates With Group Policy.

In a previous post, I discussed deploying Adobe Flash Player in an enterprise environment. I also mentioned that in order to disable the automatic update feature of Flash, you should create an MST transform file to install a custom mms.cfg.

This is all well and good, unless you are intending on installing the EXE version of Flash, and not the MSI.

Usually, I’d go MSI over EXE any day of the week, but Flash Player is a fickle b*tch of an install. For some reason, I was seeing plenty of MSI installations fail while using SCCM 2007. Most of the failures related to certain files not being marked for installation. The following event log entry could be observed on the machines.

Product: Adobe Flash Player 10 ActiveX — Error 1722.There is a problem with this Windows Installer package. A program run as part of the setup did not finish as expected. Contact your support personnel or package vendor. Action NewCustomAction1, location: C:\DOCUME~1\<username>\LOCALS~1\Temp\InstallAX.exe, command: -install activex -msi

For this reason, I bailed out and went with the EXE installation, which so far, when used with the new silent install switch (-install) works flawlessly.

Now, obviously we can’t transform an EXE, so I’ve had to come up with the following CMD script which can be applied to computer startup through the use of a Group Policy Object.

ECHO AutoUpdateDisable=1 > %WinDir%\System32\Macromed\Flash\mms.cfg
ECHO DisableProductDownload=1 >> %WinDir%\System32\Macromed\Flash\mms.cfg

The nice thing about this script is that it will only run if the Macromed folder exists.

Playing MKV Videos on Your XBOX360.

Once upon a time, before my wicked bad home cinema setup, I struggled long and hard to find a solution to play MKV video files on my television. Aside from the TV, the only bit of kit I had hanging off it was my beloved XBOX360.

After much research, I found out that I didn’t actually need anything else at all! With the help of this nifty bit of software, you can ‘remux’ a MKV video into something the XBOX360 will decode straight out of the box, the trusty MP4 video format.

The software is called XenonMKV. Readers of my blog will probably know I’ve written about this software before. I have much love for it. It’s simple to use, pretty quick, and gets the job done. Seeing as all the software is doing is stripping the video and audio out of it’s MKV container, it’s far, far quicker than conversion.

Sadly, there is a downside, although strictly the fault of Microsoft, not XenonMKV. All video files (besides WMV) are restricted to a 4gb maximum file size. Though XenonMKV caters for this by offering the option to break movies down into 4gb bite site nuggets, it’s still a royal PITA. The other downside is that audio is reverted to 2.1 stereo. Bye bye DTS track. The optimist inside of me wonders if Microsoft will ever unblock these features. The realist inside guesses probably not.

Deploying Adobe Reader Updates in Enterprise Environments.

Anyone who works with software deployments will know where I’m coming from on this. Adobe Reader has to be the single most time consuming piece of software when it comes to software packaging and distribution. With such a large user base and ever increasing targeted threats, it’s no wonder we find ourselves with critical updates to deploy. Often more than one a month.

The trouble with Adobe Reader updates is that they aren’t particularly easy to distribute. Sure, you can download the MSI installer from Adobe’s website and use the Adobe Customisation Wizard to create a neat little MST file to transform the install with all your company’s standard settings, but have you ever tried installing the new MSI over a previous version? Not so easy now huh.

For some unknown reason, Adobe engineer their Reader installations in such a way that simply deploying the new MSI isn’t enough. For instance, you can’t simply push out Adobe Reader 9.3.3 and hope that it updates all the previous 9.3.2 installations. You first have to uninstall all previous versions.

Adobe updates usually come in the form of MSP files. These files are designed to patch your existing installation points. It’s important to note that this is only the case for quarterly updates. Security updates cannot be used to patch your administrative installation point.

For this example, I’m going to patch my Adobe Reader 9.3.0 administrative installation point with the MSP for 9.3.3.

Oh but wait, another fly in the ointment. You can’t patch a 9.0 administrative point with 9.3.3 directly. You must follow this order of patching:

9.3.0 > 9.3.2 > 9.3.3

Start by downloading all of your files. You’ll need:

• Your 9.3.0 administrative point
• AdbeRdrUpd932_all_incr.msp
• AdbeRdrUpd933_all_incr.msp

Slipstreaming Updates into the Administrative Installation Point.

Fire up a command line window, and run the following. This command will integrate your MSP with your installation point.

msiexec.exe /a "path to acroread.msi in admin point" /p "path to AdbeRdrUpd932_all_incr.msp" /qb

You’ll notice the installer wizard configuring your computer. Note that this is actually configuring your installation point, not your computer.

Repeat the above with the AdbeRdrUpd933_all_incr.msp file. You will now have an installation point with Adobe Reader 9.3.3 ready to roll.

Deploying the Updated Version.

If like me you have Microsoft System Center Configuration 2007 at your disposal, you can make use of my batch file script that I have created to remove all previous versions of Adobe Reader prior to installing the new 9.3.3 version. Simply set the script to run before the installation for Adobe Reader 9.3.3 and you should find the install takes place with no errors.

For the script to work fully, you’ll need to add the MSIZap executable into the same folder as the script. This can be downloaded for free as part of the Windows Installer Cleanup Utility (found here…). You only need msizap.exe for the script to work, forget about the other files. MsiZap is a very useful tool. Check out the command line syntax I use and experiment to your hearts content.

If you only have Group Policy at your disposal, I’m sure it wouldn’t be too hard to modify the script to call the install after the uninstalls have taken place. Hope this helps!

REM *** MSI Uninstall Adobe Reader 6
msiexec.exe /x {AC76BA86-7AD7-1033-7B44-A00000000001} REBOOT=Supress /qn
REM *** MSI Uninstall Adobe Reader 7
msiexec.exe /x {AC76BA86-7AD7-1033-7B44-A70900000002} REBOOT=Supress /qn
REM *** MSI Uninstall Adobe Reader 8.0
msiexec.exe /x {AC76BA86-7AD7-1033-7B44-A80000000002} REBOOT=Supress /qn
REM *** MSI Uninstall Adobe Reader 8.1
msiexec.exe /x {AC76BA86-7AD7-1033-7B44-A81000000002} REBOOT=Supress /qn
REM *** MSI Uninstall Adobe Reader 8.1.4
msiexec.exe /x {AC76BA86-7AD7-1033-7B44-A81300000003} REBOOT=Supress /qn
REM *** MSI Uninstall Adobe Reader 9.0
msiexec.exe /x {AC76BA86-7AD7-1033-7B44-A90000000001} REBOOT=Supress /qn
REM *** MSI Uninstall Adobe Reader 9.1
msiexec.exe /x {AC76BA86-7AD7-1033-7B44-A91000000001} REBOOT=Supress /qn
REM *** MSI Uninstall Adobe Reader 9.2
msiexec.exe /x {AC76BA86-7AD7-1033-7B44-A92000000001} REBOOT=Supress /qn
REM *** MSI Uninstall Adobe Reader 9.3
msiexec.exe /x {AC76BA86-7AD7-1033-7B44-A93000000001} REBOOT=Supress /qn
REM *** Zap Uninstall Adobe Reader 6
"%~dp0msizap.exe" TW! {AC76BA86-7AD7-1033-7B44-A00000000001}
REM *** Zap Uninstall Adobe Reader 7
"%~dp0msizap.exe" TW! {AC76BA86-7AD7-1033-7B44-A70900000002}
REM *** Zap Uninstall Adobe Reader 8.0
"%~dp0msizap.exe" TW! {AC76BA86-7AD7-1033-7B44-A80000000002}
REM *** Zap Uninstall Adobe Reader 8.1
"%~dp0msizap.exe" TW! {AC76BA86-7AD7-1033-7B44-A81000000002}
REM *** Zap Uninstall Adobe Reader 8.1.4
"%~dp0msizap.exe" TW! {AC76BA86-7AD7-1033-7B44-A81300000003}
REM *** Zap Uninstall Adobe Reader 9.0
"%~dp0msizap.exe" TW! {AC76BA86-7AD7-1033-7B44-A90000000001}
REM *** Zap Uninstall Adobe Reader 9.1
"%~dp0msizap.exe" TW! {AC76BA86-7AD7-1033-7B44-A91000000001}
REM *** Zap Uninstall Adobe Reader 9.2
"%~dp0msizap.exe" TW! {AC76BA86-7AD7-1033-7B44-A92000000001}
REM *** Zap Uninstall Adobe Reader 9.3
"%~dp0msizap.exe" TW! {AC76BA86-7AD7-1033-7B44-A93000000001}

SCCM Custom Report: List Workstations That Haven’t Rebooted in X Days.

This custom report can be useful for identifying workstations that have not rebooted recently. I use this report to identify users that may not have received the latest Group Policy settings or other items that require a reboot to be enforced. As well a report query, you must also add a prompt (no code necessary) named ‘Days‘. This is the variable that will store the amount of days you wish to search back. Set the default to 7 and do not allow nulls.

SELECT
CS.Name0 AS [Hostname],
CS.UserName0 AS [Last User],
DateDiff(Day, OS.LastBootUpTime0, GetDate()) AS [Uptime (in Days)],
OS.LastBootUpTime0 AS [Last Reboot Date],
WS.LastHWScan AS [Last Hardware Inventory]
FROM
DBO.v_GS_WORKSTATION_STATUS WS LEFT OUTER JOIN DBO.v_GS_Operating_System OS ON WS.ResourceID = OS.ResourceID
LEFT OUTER JOIN DBO.v_GS_COMPUTER_SYSTEM CS ON CS.ResourceID = OS.ResourceID
LEFT OUTER JOIN DBO.v_GS_SYSTEM SYS ON SYS.ResourceID = OS.ResourceID
LEFT OUTER JOIN DBO.v_R_SYSTEM RSYS ON RSYS.ResourceID = CS.ResourceID
WHERE
SYS.SystemRole0 = 'Workstation' AND DateDiff(Day, OS.LastBootUpTime0, GetDate()) > @Days
ORDER BY
CS.Name0

SCCM Custom Report: All Servers Rebooted in the Last 7 Days.

This custom report for SCCM 2007 allows an administrator to determine which servers have been rebooted in the last 7 days. If you wish to change the 7 day interval, all you need to do is change the number 168 to the number of days, specified in hours.

SELECT
CS.Name0 AS [Hostname],
RSYS.Description0 AS [Directory Description],
DateDiff(Hour, OS.LastBootUpTime0, WS.LastHWScan) AS [Uptime (in Hours)],
OS.LastBootUpTime0 AS [Last Reboot Date],
WS.LastHWScan AS [Last Hardware Inventory]
FROM
DBO.v_GS_WORKSTATION_STATUS WS LEFT OUTER JOIN DBO.v_GS_Operating_System OS ON WS.ResourceID = OS.ResourceID
LEFT OUTER JOIN DBO.v_GS_COMPUTER_SYSTEM CS ON CS.ResourceID = OS.ResourceID
LEFT OUTER JOIN DBO.v_GS_SYSTEM SYS ON SYS.ResourceID = OS.ResourceID
LEFT OUTER JOIN DBO.v_R_SYSTEM RSYS ON RSYS.ResourceID = CS.ResourceID
WHERE
SYS.SystemRole0 = 'Server' AND DateDiff(Hour, OS.LastBootUpTime0, GetDate()) < 168
ORDER BY
CS.Name0