Deploying Java and Adobe Reader via Group Policy

Java:

Firstly download the latest Java Windows offline installer here.

Run the installer, and wait for the Welcome screen to appear. Next, navigate to the following directory, where USER_NAME is the name of the logged on user, and jre_VERSION is the name of the version of Java that you have just extracted:

C:\Users\USER_NAME\AppData\LocalLow\Sun\Java\jre_VERSION

In this folder you will find an msi file and a data.cab file. Copy the jre_VERSION folder to you network deployment point, and then add the msi file path to a new package in the software installation section of the Group Policy Object (GPO) that you wish to deploy Java to.

 

Adobe Reader:

Simple Method:

Download the most recent MSI file from ftp://ftp.adobe.com/pub/adobe/reader/win and deploy that to a new package in the software installation section of the GPO that you wish to deploy to e.g. AdbeRdr11000_en_US.msi. Note that Adobe only issue MSI files for the major releases e.g. 11.0.00.

Complex Method

This method includes how to patch the MSI file of the major release outlined in the simple method to include all the latest security patches. Firstly download the MSI file for the major release which you want to patch and place it in a folder on your computer e.g. C:\ADOBEREADER

Next download the .exe file for the update version which you want to patch to e.g. 11.0.01 from ftp://ftp.adobe.com/pub/adobe/reader/win and extract the contents using the following command, where _VERSION is the version number of the file you downloaded:

AdbeRdr_VERSION_en_US.exe -nos_ne

e.g. AdbeRdr1101_en_US.exe -nos_ne

This will extract the contents of the .exe file to a subfolder in the C:\ProgramData\Adobe\Setup folder. Copy the .MSP file contained in this folder to the C:\ADOBEREADER folder you created earlier. From the command prompt navigate to the C:\ADOBEREADER folder and run the following command where MSI_VERSION is the version of the MSI file that you are updating and PATCH_VERSION is the version of the patch that you are applying :

msiexec /a AdbeRdr_MSI_VERSION_en_US.msi /p AdbeRdr_PATCH_VERSION.msp

e.g. msiexec /a AdbeRdr11000_en_US.msi /p AdbeUpd11001.msp

Click through the steps of the installer, and then click finish. Your .msi file has now been patched

Finally, copy your new patched msi file to your network deployment point and create a new package in the software installation section of the GPO which you wish to deploy Adobe Reader to.

References:

How do I deploy Java using Active Directory across a network?

How to extract an MSI file from the EXE for Adobe Reader

Windows Server 2008 R2 SP1 install breaks RDP

After installing Service Pack 1 via windows update on a Windows Server 2008 R2 machine the other day, I discovered that I could no longer use remote desktop connection to access the server remotely. At first I wasn’t sure if the whole service pack installation was botched, but further testing revealed that all other functions of this server were operating normally. A quick google search showed that I was not alone in experiencing this problem, in fact there is enough information out there to solve this without another blog post from yours truly, but there is a bit of conflicting information so I thought I would document my experience to hopefully help others.

The problem manifests itself like this:

You try to RDP the affected server and it goes through the enitre logon process, and just when you think it is going to fire up the remote desktop it bombs out. An event was logged in the application log in my case event 4005 with a source of Winlogon, stating ‘The Windows logon process has terminated unexpectedly’ (shown below), although I have read of slightly different errors on other blog posts. Checking the Terminal Services logs indicate that the logon has completed successfully.

Event 4005 Source Winlogon after Service Pack 1 install on Windows Server 2008 R2

This situation it turns out, occurs when both KB2621440 and KB2667402 are applied to a system before Service Pack 1 is applied, as they effectively leave some of the RDP DLL files out of sync, specifically rdpcorekmts.dll. Now, alot of the posts I read online stated that you simply needed to uninstall the KB2777402 update, reboot, and then reapply it to solve this problem. I tried this first and it did not work. Various posts also stated that RDP started working after the removal of this patch, again this was not the case for me although I am sure it is correct in some cases.

So the fix I used in the end was this:

Firstly I uninstalled both KB2621440 and KB2667402 via Control Panel, Uninstall a Program, View Installed Updates, and then rebooted the server. I expected the DLLs to be set back to a working state at this point but this was not the case. Luckily in my case I had physical access to the server. Other posts state that the two updates can be uninstalled remotely using the following commands if you do not have that luxury:

wmic /node:<SERVER> /user:<USER> process call create “powershell wusa /uninstall /kb:2667402 /quiet /forcerestart”

wmic /node:<SERVER> /user:<USER> process call create “powershell wusa /uninstall /kb:2621440 /quiet /forcerestart”

Note, that the commands above will restart the server

As RDP still didn’t work for me at this point contrary to other information, I ran:

sfc /scannow

This picked up some issues and required a reboot. After rebooting the server I was able to use RDP again. That was great, but didn’t help with the fact that the two patches that were removed were to address the Critical RDP vulnerability MS12-020. I certainly didn’t fancy not applying these patches to this server so I reapplied KB2621440 and KB2667402 via Windows Update, and rebooted the server. Thankfully after this I had a fully patched server and working RDP.

If you need to do all of this remotely and find that you still can’t RDP the server after removing the two patches using the commands above I recommend running sfc /scannow using PSEXEC:

psexec \\SERVER sfc /scannow

Then when the scan is finished performing a remote reboot using:

psexec \\SERVER shutdown -r -t 01

This should get your RDP back to a working state, and then you can reapply the removed updates. I have not corfirmed this but expect this fix will also work for Windows 7.

Installing or Renewing a 2048 bit SSL Certificate on Citrix Access Essentials/Xenapp Fundamentals

I had to renew a 2048 bit Godaddy SSL certificate on a Citrix Access Essentials server today. This article on the Citrix knowledgebase explains how to install the certificate in Quick Start, but is a bit light on detail for the IIS part so I thought I would document it here.

Firstly you need to generate a certificate request or renewal request on the Citrix Access Essentials or Xenapp Fundamentals external website in IIS manager. Right click the website and choose ‘properties’, then click on the  ‘Directory Security’ tab. In the ‘Secure Communications’ section click on the ‘Server Certificate’ button, and the server certificate wizard will start. Click Next, and the following screen will appear:

Creating the renewal or certificate request

In this case I was renewing the existing 2048 bit certificate, so selected ‘renew the current certificate’ and clicked next. On the next screen choose ‘prepare the request now but send it later:

Preparing the request

Finish the wizard, and save the request for processing with your SSL provider. In this case the provider is Godaddy, but the process will be similar for other providers. Log into Godaddy, select the certificate you want to renew (assuming you have already purchased the renewal credit), and choose ‘Request Certificate’ .

Requesting a new certificate using Godaddy

   

On the next screen select ‘Third Party or Dedicated Server, and then paste the contents of the certificate request that you generated in IIS into the CSR field as shown:

Processing the CSR with Godaddy

Submit the request and then wait for Godaddy to process it, completing any necessary domain control, or other validation processes that may be required. Once the certificate processing is complete, download your new certificate from Godaddy. If this is the first time you have installed a Godaddy certificate on the server you will also need to install intermediate certificates that come in the zip file on your server. Further documentation on this can be found on the Godaddy website here.

Next install the new certificate using IIS manager. Again, right click the Citrix external website and choose ‘Properties’, then click on the ‘Directory Security’ tab. In the ‘Secure Communications’ section click on the ‘Server Certificate’.  In the wizard choose ‘process the pending request and install the certificate’.

Processing the pending certificate request in IIS

Browse to the new certificate .crt file you downloaded from Godaddy and click next. You may need to select ‘All files’ to view this file.  

Now the next screen can cause a bit of a gotcha. By default the wizard wants to choose standard SSL port 443 to install this certificate on. If you select this port it will conflict with Citrix and cause an error message when accessing the website after installing the certificate. Make sure you select a different port in the wizard, such as 444 to prevent a conflict with Citrix Access Essenstials, then click ‘Next’.

Select an SSL port other than 443, such as 444 in the wizard to prevent a conflict with Citrix

Failure to change the port will result in the error ‘Bad Gateway! The proxy server received an invalid response from the upstream server. Error 502’, which can be seen below:

Error message when installing new SSL certificate on Citrix Access Essentials/Xenapp Fundamentals Bad Gateway error 502

Review the final screen, and complete the wizard. Finally, run up the Citrix quick start tool and choose ‘Manage External Access’, under the ‘External Access’ section. From here you can choose the new certificate to use with Citrix Access Essentials. These steps are documented in the Citrix document. After that you’re done!