Windows 2008 R2 – platformadmin.com

Using SAS92HFADD & ViewRegistry on Windows Server 2008 R2

In my earlier post on Reviewing Installed SAS 9.2 Software and Hotfixes I mentioned that I ran into a few User Access Control issues on Microsoft Windows Server 2008 R2 when using the SAS ViewRegistry Report utility and the SAS 9.2 Hot Fix Analysis, Download and Deployment Tool (SAS92HFADD).

To get the SAS ViewRegistry Report and SAS92HFADD utilities functioning correctly on Windows Server 2008 R2, the User Access Control (UAC) feature will require you to go through a few extra hoops (unless you have it disabled). UAC is a security feature that, when enabled, means that administrators log in and operate as standard users most of the time, and when they need to do something that requires elevated privileges they will be prompted by Windows (or as I also found out sometimes silently blocked). If you want more information (and a fuller explanation of UAC) then read the Microsoft document User Account Control Step-by-Step Guide.

If you run your server with UAC disabled then you can just follow the SAS instructions as normal and disregard this particular blog post. Of course running with UAC disabled is not normally recommended. I seriously considered turning it off, but decided I would try to ‘do the right thing’ and also use it as a learning experience. After a bout of UAC frustration I spoke to one of my friends who specializes in Microsoft technologies and he told me he leaves UAC enabled and tends to have an administrative PowerShell window open for when he needs to do some admin things.

In this post I’ll explain what I needed to do, in addition to the SAS provided instructions, to get those utilities working on Windows Server 2008 R2 with UAC enabled.

ViewRegistry Report

The SAS ViewRegistry Report utility is used to generate HTML and text reports listing the SAS software and hotfixes currently installed. You can also feed the output of this utility into the SAS92HFADD utility to generate another report detailing the appropriate available hotfixes that have yet to be installed, together with scripts to download and install them.

When I followed the usage note instructions for Windows and just double-clicked on sas.tools.viewregistry.jar I found nothing happened. I then opened up a command window and ran java -jar sas.tools.viewregistry.jar which gave me a bit more information as shown below:

c:\Program Files\SAS\deploymntreg>java -jar sas.tools.viewregistry.jar java.io.FileNotFoundException: C:\Program Files\SAS\deploymntreg\registry.lck (Access is denied) Exception in thread "main" java.lang.NullPointerException at com.sas.tools.viewregistry.Report.collectRegistryData(Report.java:98) at com.sas.tools.viewregistry.Report.main(Report.java:66)

I was logged on as someone who was an administrator (sas), so I knew it wasn’t a file system permission issue and must be related to UAC. To run sas.tools.viewregistry.jar with elevated permissions I right-mouse-clicked over the Command Prompt item in the Windows Start Menu, and clicked the Run as administrator menu item:

This opened an Administrator: Command Prompt window where I issued the following commands to run the ViewRegistry Report utility as an administrator:

cd "C:\Program Files\SAS\deploymntreg" java -jar sas.tools.viewregistry.jar

This time it worked, generating the DeploymentRegistry.html and DeploymentRegistry.txt files as expected.

If you expect to run the ViewRegistry Report utility regularly then you might find it easier to create the file C:\Program Files\SAS\deploymntreg\ViewRegistry.bat containing the following:

@echo off cd /d "%~dp0" java -jar sas.tools.viewregistry.jar pause

To run ViewRegistry.bat as an administrator, right-click over it in Windows Explorer and select the Run as administrator item from the pop-up menu:

SAS 9.2 Hot Fix Analysis, Download and Deployment Tool (SAS92HFADD)

The SAS92HFADD utility takes the output from the ViewRegistry Report utility and generates another report detailing the appropriate available hotfixes that have yet to be installed, together with scripts to download and install them.

SAS92HFADD for Windows is downloaded as a WinZip Self-Extractor (SAS92HFADDwn.exe). I ran this and got the following error:

It also needs to be run as an administrator. This can be done by right-clicking over the SAS92HFADDwn.exe file in Windows Explorer and select the Run as administrator item from the pop-up menu:

I now had the C:\Program Files\SAS\SAS92HFADD directory and files as expected. Into that directory I then dropped a copy of the DeploymentRegistry.txt file from a run of ViewRegistry Report utility. I actually missed this step the first time around and got the >> %%% ERROR: Unable to open DeploymentRegistry.txt error in the tool_log.txt file as explained in the SAS documentation.

Next I ran the C:\Program Files\SAS\SAS92HFADD\SAS92HFADD.exe utility. Initially it looked like it was working:

However, after a few seconds, the window closed and there were no additional files (not even a log file) in the C:\Program Files\SAS\SAS92HFADD directory. I immediately guessed this also needed to run as an administrator. I right-clicked over C:\Program Files\SAS\SAS92HFADD\SAS92HFADD.exe in Windows Explorer and select the Run as administrator item from the pop-up menu:

When it completed I had a new directory tree C:\Program Files\SAS\SAS92HFADD\WX6_1295740219 containing the following files as expected:

AnalysisReport\SAS_92_Hot_Fix_Report_WX6_1295740219.html
Log\tool_log.txt
DownloadTools\ftp_script.bat
DownloadTools\ftp_script.txt
DownloadTools\MD5_checksums.txt
DeployTools\WX6_install_script.bat

The AnalysisReport\SAS_92_Hot_Fix_Report_WX6_1295740219.html file is a report listing all of the available hotfixes that can be installed on the server (that haven’t already been installed):

The DownloadTools\ftp_script.bat file is an automatically generated script that can be run to download all the hotfixes identified in the report. I started out running this by double clicking on it in Windows Explorer. By this time I was almost certain that UAC would be a barrier, but as a learning experience I wanted to see how it would fail anyway. The following screenshot has the error message highlighted – at least there was an error message :)

I ran the FTP script again, this time by right-clicking over it in Windows Explorer and selecting the Run as administrator item from the pop-up menu:

The FTP script to download all the hotfixes ran successfully to completion this time. It took a while, as there were many hotfixes to download, but when it finished I had a bunch of hotfix executables in the DeployTools directory. Now it was time to install them.

To install the hotfixes I used the automatically generated DeployTools\WX6_install_script.bat script that silently installs each hotfix in turn. I started out running this by just double clicking on it in Windows Explorer. I guessed UAC would most likely block it, but once again I wanted to see how it would fail. It took a little while to complete, and appeared to be doing something without generating any errors, however when it had finished I could see by re-running the ViewRegistry Report utility that nothing had changed – no additional hotfixes had been installed.

I ran the install script again, this time by right-clicking over it in Windows Explorer and selecting the Run as administrator item from the pop-up menu:

I saw the command window open and all the commands flash by, possibly with errors, but way too fast for me to see – and also way too fast for the hotfixes to actually have been installed :)

The next method I tried, which worked this time, was to open a command prompt window as an administrator, change directory to the DeployTools directory and run the WX6_install_script.bat script:

The install script continued away for a while silently install each hotfix in turn:

Once the install script had completed, I went through the analysis report to ensure I did all of the outstanding manual tasks. I found the manual tasks by reading through the several linked documents in the analysis report that were tagged with a [D]. In this case it included upgrading metadata using the SAS Management Console, copying a plugins directory into a couple of locations, using the SAS Deployment Manager to rebuild a number of EAR files, and then redeploying the updated EAR files.

With all of this done I did a final check by re-running the ViewRegistry Report utility, copying over the new DeploymentRegistry.txt file, and then re-running SF92HFADD.exe. The resulting analysis report now had a nice green banner indicating that I was up to date with all of the available hotfixes.

Final Notes

This process assumes you want to install all of the available hotfixes. If your update strategy is to only install a subset of the hotfixes (such as those with alert notes) you can edit the generated ftp and install scripts to only download and apply those hotfixes you have targeted. The analysis report is a very useful document to help you determine what hotfixes are available for your platform/product mix that haven’t yet been installed. The report can also be used to help you chose which of those hotfixes are appropriate for your update strategy by reviewing the Issue(s) Addressed links.

Regarding UAC, at some point I also tried using a Windows Explorer (run as administrator) but found that the things it launched did not themselves run as administrator too. Looking back on it now, it probably would have been easier to avoid Windows Explorer completely and just use the administrative command prompt window (or PowerShell) – as my Microsoft oriented friend later suggested. I guess I could have also temporarily disabled UAC for the duration of this process and then re-enabled it afterwards. Taking this easy way out, however, would have meant I didn’t find out what I could and couldn’t do with UAC enabled, and I would have also missed out on the learning experience.

What I originally meant to be a reasonably short post has actually turned out to be much longer than I expected! If you’ve made it to the end and have any comments, or suggestions about alternative approaches, please let me know by leaving a comment below.

Resetting File Permissions in Windows Server 2008 R2

Today I needed to reset the permissions for a bunch of files in a directory on a SAS server (running Windows Server 2008 R2) so that they reverted back to the inherited permissions from the directory they were contained in (they currently had non-inherited explicit permissions for a particular user). There were too many to do by hand using point-and-click in the properties dialog so I switched to the command line.

In previous versions of Windows I had used the cacls command but I noticed in Windows Server 2008 the cacls command is deprecated and replaced with icacls. If you use the cacls command with no parameters to display the help, you will see the following message in its output:

... NOTE: Cacls is now deprecated, please use Icacls. ...

The Microsoft TechNet site has documentation for the icacls command.

To reset an individual file’s permissions you can use:

icacls file.ext /reset

Using a wildcard to reset the permissions for a collection of files also works:

icacls *.ext /reset

Resetting the permissions on a file drops any specific/custom/explicit permissions on that file and reinstates the inherited permissions from the container/folder so that the file now only has the default inherited permissions.

Reviewing Installed SAS 9.2 Software and Hotfixes

If you’ve ever needed to review which SAS® software components have been installed on your SAS servers and clients, as well as know which hotfixes may have already been installed, then you will be interested in SAS Usage Note 35968: Using the ViewRegistry Report and other methods to determine the SAS® 9.2 software releases and hot fixes that are installed.

The usage note provides instructions detailing how you can use a Java-based SAS utility (sas.tools.viewregistry.jar) to generate HTML and text reports (DeploymentRegistry.html and DeploymentRegistry.txt) of the installed software and hotfixes. With SAS 9.1.3 I used to manually maintain (error-prone) spreadsheets with this information, so I am very happy to be able to automate it with SAS 9.2 and get reliable information.

Now that you have this information the next logical step would be to determine which hotfixes haven’t been installed, but might need to be, then download and install them…

Well, the even better news is that SAS Institute also provide the SAS 9.2 Hot Fix Analysis, Download and Deployment Tool (SAS92HFADD). SAS92HFADD is another utility that compares the currently installed hotfixes against a freshly downloaded list of currently available hotfixes for the software you have installed. It generates an HTML analysis report listing all of the appropriate hotfixes together with links to the list of issues, install instructions and download for each hotfix. It even adds annotations to those hotfixes that require a bit more attention because they have dependencies or post-installation instructions (like rebuilding and redeploying web apps). As well as the report you also get a script to download all of the hotfixes and another script to silently install them all. I was very impressed. I think I’m going to like using this utility :)

One thing that tripped me up when I first tried to run SAS92HFADD (because in my excitement I skimmed over the instructions too quickly), was that you need to manually run ViewRegistry to get a DeploymentRegistry.txt file to drop into the SAS92HFADD directory. It would be great if a future version did this automatically. I’d also be quite keen to see it all managed from a central admin console that reaches out to all the SAS servers and clients in an organization to collect this information and optionally push out selected hotfixes. Perhaps this could be a suggestion for the SASware Ballot?

For those who run SAS software on Windows Server 2008 R2, you might run into the same User Access Control issues I did, so I’ll do a follow up post specifically on using ViewRegistry and SAS92HFADD on Windows Server 2008 R2.

SAS Metadata Backup on Windows 2008 R2 64-bit

I was trying to run a manual SAS Metadata Server backup (OMABAKUP) on Windows 2008 R2 64 bit today. It failed! I run metadata backups many many times so I was sure all the normal prerequisites were in place but this was the first time I had run one on Windows 2008 R2 64 bit … hmm … I remembered seeing a SAS usage note about metadata backups on Windows 2008 a week or so back. A quick search found SAS Usage Note 38869: What credentials are needed when running a SAS® Metadata Server backup in batch on Windows 2008. It described the error I saw in the SAS log perfectly!

The resolution was to Run as administrator. Even though I was logged in to Windows as an Administrator I still had to explicitly run the SAS program in an administrative context (it’s a Windows security thing). As mentioned in the usage note, this is also documented in the SAS® 9.2 Intelligence Platform: System Administration Guide, Second Edition, Chapter 11 Using the %OMABAKUP Macro to Perform Backups and Restores, in the section Ensuring Appropriate User Credentials.

So I had a SAS usage note describing the problem and the solution. The trouble was I couldn’t quite get the instructions in the SAS usage note to work for me. When I right click over the Command Prompt window (or a PowerShell window for that matter) I don’t get a Run as administrator item. What did work for me though was to right mouse click over the Command Prompt item in the Windows Start Menu, and click the Run as administrator menu item – here’s a quick screenshot to clarify.

That opens a Command Prompt window running in an administrative context so I could then change to the metadata server directory and run the backup:

cd C:\SAS\EBIEDIEG\Lev1\SASMeta\MetadataServer MetadataServer.bat -backup

… a quick check of the SAS log shows everything worked as expected this time.

SAS 9.2 Mid Tier Support for Windows 2008 R2

To date I had avoided Windows 2008 R2 because, until recently, it was not supported for the SAS 9.2 Mid Tier. I had read in SAS Installation Note 36616: SAS® 9.1.3 Service Pack 4 and SAS® 9.2 support for Microsoft Windows Server 2008 that support for 2008 R2 was coming with the release of the version 4.3 mid-tier apps. Now that release has happened I checked back with the usage note to see if it had been updated and was pleased to see the following:

“The subsequent delivery, SAS 9.2 (TS2M3), Revision 10w46, is now available. This delivery includes the remainder of the 4.3 release, which is the SAS Content Server and SAS Web-based clients (for example, SAS Web Report Studio and SAS Information Delivery Portal).”

Something I also noticed at the bottom of SAS Note 36616 was a link to SAS Installation Note 40501: Java 6 Update 14 or later is required when you install SAS® 9.2 in the Microsoft Windows 7 or Microsoft Windows Server 2008 R2 operating environments. That note points out that for Windows 2008 R2 you also have to use Java 6 (rather than Java 5) and provides the following information on when Java 6 support started:

“Prior to SAS 9.2, Rev. 09w51, JRE 1.6 was not supported. In order to use JRE 1.6, you need to install SAS 9.2 09w51 or later.”

There is an explanation of the meaning of the revision number in SAS Installation Note 35627: Determining your SAS® 9.2 release. SAS 9.2 Revision 10w46 as mentioned in 36616 is more recent (being 2010 week 46) than SAS 9.2 Revision 09w51 mentioned in 40501 (which is 2009 week 51).

So it looks like I can try out Windows 2008 R2 now – as long as I also remember to use Java 6 and get SAS 9.2 Revision 10w46 or later. As a bonus I now understand SAS 9.2 revision numbers. :)