The internet is full of complains that Admin Pack for Windows 2003 cannot be installed due to protected Windows files. I guess that this can happen for various reasons, but I have found a solution for at least one of the cases – when the server where the installation of Windows 2003 Admin Pack fails is virtualized.
So, we have two servers – Windows 2003 Server with Active Directory installed as Domain Controller (server #1) and VM with Windows 2003 Server that is a member of this domain (server #2). The need – administer DNS and DHCP settings of AD remotely, but corresponding MMC snap-ins are not available by default on non-DC machines. The correct way is to install ADMINPACK.MSI, available from Windows 2003 installation CD-ROM or from Microsoft Download Center. (Of course, you can always open an RDP session to a DC – but this does not address the real need.)
However, the installation suddenly shows a message “The Windows Installer service cannot update one or more protected windows files” and rolls back everything that was already installed. The Event Viewer reveals error numbers (“Error 1933. … SPF Error: 1223.”) and the list of protected files – but this does not really help. So, what can we do about that?
In fact, the solution is really simple. Running the same installation via the console RDP session (or in the vSphere console) reveals the real cause for the failure – the Admin Pack install needs Windows 2003 installation CD-ROM, but for some reason does not tell that on non-console sessions. After the requested CD is provided (for VMs, this can be done by mounting the CD image in vSphere or via DaemonTools), the installation was able to complete successfully. Continue reading “How to install Admin Pack for Windows 2003 on Virtual Machine”
Imagine that you’ve just installed Citrix Receiver for Windows 3.0. The nice broadcast icon already appears in system tray, but Preferences item in the context menu is disabled for some reason. The system logs has no relevant errors, and Citrix is not mentioned at all under Programs in the Start Menu. This is the time to read the documentation and discover that Microsoft .NET 2.0 or higher is required for Citrix Receiver to operate. Unfortunately, Receiver installation process does not verify that .NET is actually installed on your machine…
You can turn on debug logging with “trace” utility from “pdadmin” shell via “server task” call. Here is the general format of the call:
server task <instance>-<host> trace set <component> <level> file path=<path>
The parts in the angle brackets should be replaced with appropriate values:
- <instance> – the name of WebSEAL instance
- <host> – hostname of the server that runs WebSEAL
- <component> – name of the component to turn logging on for (see below)
- <level> – log level to use (1 to 9, where 1 is the most detailed; use 0 to turn logging off)
- <path> – filename of the log file to fill with the information
The list of the components can be obtained with “trace list” command. Among the useful WebSEAL-related components:
- pdweb – trace all WebSEAL-related information
- pdweb.debug – list of HTTP header going trough WebSEAL
- pdweb.snoop – same, but including message body
- pdweb.snoop.client – same, but only for data sent between WebSEAL and the web client
- pdweb.snoop.jct – same, for data sent between WebSEAL and the actual web servers (aka “junctions”)
In the example below you can see how to turn on debugging of the web traffic that goes through WebSEAL. The log will go to “C:\pdweb.debug” file. [ Update (April 2013): How to open the ‘pdadmin’ shell. ]
Enter User ID: sec_master
Enter Password: ********
pdadmin sec_master> server task default-webseald-tameb trace set pdweb.debug 2 file path=C:\pdweb.debug
You can read more about “server task trace” in the TAMeb documentation.
Did it ever happen to you that you want to revert some VM to another snapshot and get “The object has already been deleted or has not been completely created” error message? It is really painful, especially if you lab heavily relies on excellent snapshot functionality provided by vSphere… It appears that sometimes it can be fixed by deleting the VM from the inventory and adding it back. The process is really simple, but requires administrative credentials.
So, here it goes:
- Go to the Summary tab for your VM, find the relevant datastore and choose “Browse Datastore…” option.
- Find the folder that belongs to your VM and make sure you see the “.vmx” file (you’ll need it in step 5).
- Go back to your VM in the vSphere tree and choose “Remove from Inventory” in the context menu. Be careful – “Delete from Disk” is the next option, and it is not reversible!
- Wait while vSphere performs your request.
- Go to datastore window, open context menu of the “.vmx” file and choose “Add to Inventory”
- Go through the wizard, selecting relevant options for VM import.
That’s all – wait until the VM will be fully imported and try to revert to your favorite snapshot now.
Did it happen to you that your lab WebSEAL instance suddenly stopped working? Everything seems to be up and running, but any regular request to port 444 results in “Internet Explorer cannot display the webpage”? Well, it happened to me several days ago. Testing the same URL in Google Chrome revealed the possible cause – “ERR_SSL_PROTOCOL_ERROR”. Additional test revealed that HTTP traffic on port 81 (which is typically not used) is served correctly.
I’ll save you from reading the frustrating troubleshooting details. The bottom line is simple – the self-signed SSL certificate supplied with IBM WebSEAL expired on August 27, 2011. This is the certificate that is used by default in many labs, including mine. The fix is really simple – if you know where to look and what to do. Continue reading “Fixing WebSEAL that suddenly stopped responding to HTTPS”