Disabling a network card when running sysprepping a Windows machine is easy. Two things need to happen:
Disabling a network card when running sysprepping a Windows machine is easy. Two things need to happen:
I’m finalizing a Windows 2003 R2 build that will become our gold image, which will be the source of all new server deployments within our organization. One challenge I had to overcome was getting the CD-ROM/DVD drive to be set to drive Z: after the syspreped image is cloned and booted.
Many people are familiar with changing drive letters within the Device Management tool aka devmgmt.msc. I needed to automate this task so the CD-ROM drive, which shows up as drive D on my image after running sysprep, would be automatically set to drive Z.
To accomplish this, I needed three things:
The applicable portion on my sysprep.inf file:
My changeletter.cmd file:
diskpart /s c:\drives.txt
My drives.txt file:
select disk 0
select volume d
assign letter z noerr
Put all these pieces together, and your CD/DVD drive should be changed to drive letter Z after booting up the sysprep’ed image. Note that in the [GuiRunOnce] section of the sysprep.inf file, the part to the left of the equals sign is Command0, as is Command zero. If you wanted to run additional scripts, the next would be Command1, followed by Command2, etc.
When trying to install Dell OpenManage Server Administrator (OMSA) on a PowerEdge R610 server running Windows Server 2003 R2, I received the following error from the prerequisite checker:
“This is not a supported server. Server Administrator software can only be installed on supported servers.”
I recevied this error when trying to install OMSA 5.4, 5.5, and 6.0.1. To get around the error you can run the installer with the option to bypass the prerequsite checker. To do so, from command prompt, run the following:
C:\OpenManage\windows\SystemsManagement\msiexec /i SysMgmt.msi SYSTEMCHECK=NO
Dell’s official documentation says version 5.4 and 5.5 of OMSA are not supported on the R610, but it runs great on many systems in my environment.
McAfee has an uninstaller tool, MCPR.exe, that it recommends running after removing one of their Windows products through Add/Remove programs. This tool runs on Windows 2000, XP, and Vista. See document 107083 for details.
Internet Security Suite
PC Protection Plus
Running the McAfee Consumer Product Removal tool (MCPR.exe) removes all 2005, 2006, 2007, and 2008 versions of McAfee consumer products.
It seems like Adobe is releasing new Flash Players on a regular basis to deal with security issues. It’s important to remove old versions of Flash Player prior to installing the new version. Otherwise, you’ll keep remnants of the vulnerable versions on your system.
Here’s a very simple way to uninstall your previous version of Flash Player:
1) Download the most recent Flash uninstaller.
2) Close all browsers and applications that may use Flash Player, including AOL Instant Messenger, Yahoo Messenger, MSN Messenger, or other Messengers.
3) Run the uninstaller with the /silent option:
You can also test to verify Flash Player has been uninstalled.
Note: Internet Explorer users may have to reboot to clear all uninstalled Flash Player ActiveX control files
MSTview.exe is a free, portable transform (.mst) viewer that is found in the Office 2003 Editions Resource Kit, as well as the Office XP Resource Kit. Rather than install the entire Resource Kit just to get this one file, try this:
1) Download the Office 2003 Editions Resource Kit (ork.exe) from Microsoft.
2) Browse to the ork.exe file you downloaded, and using your favorite file compression program (I use Universal Extractor, it’s free) and extract the files to your downloaded directory. You should end up with 7 newly extracted files, and the important one is ork.cab. Feel free to delete the other files you extracted.
3) Again using your favorite file compression program, browse to the ork.cab file, and extract that file. You should end up with about 66 new files. The only one you want is mstview.exe, you can delete the rest.
4) Run mstview.exe, and you’ll be presented a window asking for the path to the .msi file and it’s corresponding .mst. Browse to the location of both files, and your .mst file will open automatically.
Now, if you actually want to edit your .msi/.mst file, try to download Orca, a part of the Windows Server 2003 SDK. It isn’t the easiest program to find, so Aaron Stebner has posted a link to it here. InstallShield also has instructions on how to obtain Orca. KB255905 has details on how to use Orca to edit your Windows Installer .msi/.mst files.
Note that I usually use the following method to extract files from a .msi file, but this Resource Kit gives the following error when I try to do this:
Creation of administrative installation images is not supported for Microsoft Office 2003 Resource Kit.
For what it’s worth, the inspiration for this post was that I was using this method to deploy the updated Groupwise client to a different WAN, and I couldn’t remember if the groupwise.mst file contained any location specific information. My Internet connection was too unreliable to download Orca, so I ran mstview.exe and was quickly able to view the transform file.
Before you do anything else, if you’re running an OES version prior to SP2, make sure you prepare the OES server for patching. A Cool Tool is available to make this process easier. If you are running OES SP2, read TID3045794 for an overview of the process.
That being said, I have a brand new OES SP2 Linux server, and couldn’t easily figure out how to patch it using Red Carpet’s rug from the console. The documentation made patching sound so easy, but I kept getting activation not found errors.
After doing some searching I came across TID10097537, the OES Red Carpet FAQ that helped me through the activation process, which is a prerequisite for being able to download and install the patches.
The process I followed was:
From the console (as root), I typed
rug set rollback=true
to enable the ability to rollback to a previous patch version. Next, to view my services I typed
The OES service was not listed, so I added it by typing
showed me that the OES service was number 1 in the list, so I activated the service by typing
rug act -s service-list-number MyActivationCode MyEmailAddress
The activation code is case sensitive. If you don’t have an activation code, check out the instructions here regarding how to get one.
Once my server was activated, I needed to subscribe to the OES patch channel. I did so by first listing the available channels
If the channels still don’t appear after activation, see TID10098375 for the fix.
Both the oes and oes-edir88 channels were available, so I subscribed to them by typing
rug sub oes
rug sub oes-edir88
Now that I was subscribed to my two channels, I listed the available patches by typing
437 patches were available, but since I’m on a network that has 5 T-1s with almost no utilization today, I decided to download and install them all by typing
rug pin –entire-channel oes
rug pin –entire-channel oes-edir88
Then I waited for the process to complete, and to avoid unwanted memory consumption after using the Red Carpet client I typed
rug set max-allowed-memory 40
Once you see transaction finished, I like to reboot the server and verify the patches didn’t break anything, but this is not mandatory. To do this quickly from the console, type
shutdown -r now
Also check /var/log/messages and the logs located in /var/log/rcd for any errors.
One quick note: prior to OES SP2, rug should always be used to apply patches rather than the Red Carpet GUI. See the section labeled Should I use rug (command line interface) or Red-Carpet (gui interface) to manage updates?
If you have problems installing OES patches, see TID3739116 for an updated Red Carpet daemon or TID10100002, Troubleshooting the OES SP2 Patch Process. Additional information can also be found at TID3377050, the Guide to Patching Novell Linux Products.
Beginning with Groupwise 6 SP1 I deployed the Groupwise client using the .aot files included with the client setup program . Starting with Groupwise 7 you’ll need to deploy the client via Zenworks using .msi files.
First, copy the client directory to a network share where users have at least read and file scan rights.
Next use the Groupwise Tuner utility (found in the \admin\utility\gwtuner directory) to customize the installation for your environment. This utility will create a groupwise.mst file in network \client\win32 directory.
Once your .mst file has been created, from ConsoleOne create a new application object for a application that has an .MSI file
Enter the path to the groupwise.msi file on the network. I personally always use UNC mappings
Give the new object a meaningful name
Add any availability rules
Create user/computer associations
Once the object is created, right click your new Application object, and select properties. Navigate to the msi – transforms tab, select add, and enter the path to the .mst file created by the Groupwise Tuner utility.
If Groupwise will be used by more than one user per machine, include the ALLUSERS=1 value on the msi – properties tab.
You should now be able to deploy the Groupwise 7 client using Zenworks.
For more information on the deployment process, see TID3492700. Note that this document says that you must deploy isscript1050.msi with the client installation, but that was not the case for me with the 7.0.2 hot patch 1a client installation.
According to the readme file included with Netware 6.5 Service Pack 6 (Last modified: 06Nov2006),
“If you have eDirectory 8.8 installed on the server, copy the dhost.nlm (dated 18Sep2006 09:36AM) to the server’s sys:\system directory and reboot the server before applying the Support Pack. “
Then the Novell eDirectory 8.8 Readme Addendum was released and has become a living document listing the known issues with eDirectory 8.8.
then Novell released eDirectory 8.8.1, which they had security problems. To fix this issue, they released eDirectory Post 8.8 SP1 FTF1 for NW & Win32 which is a patch for the compromised eDirectory 8.8.1 support pack. This TID states:
“NOTE: This patch contains a new DHOST.NLM (dated 10-16-2006 05:29pm) that must be installed on a NetWare 6.5 server running eDirectory 8.8.1 prior to installing Support Pack 6.”
Which is fine and dandy, except here came Security Services 2.0.4, which notes:
“If you install NetWare 6.5 SP6 and upgrade to eDirectory 8.8 or eDirectory 8.8 SP1, the eDirectory install will backrev NMAS, PKIS and NICI. If this happens, applying this patch is appropriate.”
“If you are installing the Security Services 2.0.4 patch on a NetWare 6.5 server with eDirectory 8.8 SP1 installed, you MUST apply “eDirectory Post 8.8 SP1 FTF1″ for NetWare (or greater) prior to applying the Security Services 2.0.4 patch or the install will hang. If you did not apply the “eDirectory Post 8.8 SP1 FTF1″ (or greater) patch before installing the Security Services 2.0.4 patch and the installation hangs, apply the above patch and rerun the Security Services 2.0.4 install.”
Continuing the saga, then came eDirectory Post 8.8 SP1 FTF2, which stated:
“This is being provided to resolve known security issues as well as critical defects. NOTE: This patch contains a new DHOST.NLM (dated 2007-01-25 10:09:46) that must be installed on a NetWare 6.5 server running eDirectory 8.8.1 prior to installing Support Pack 6.”
Since I have Netware 6.5 and eDirectory 8.8.x, before I update my servers, I’m going to:
1) Carefully read the readme file for NW65SP6 before doing anything.
2) Search the Novell support knowledge base for updated TIDs on eDirectory 8.1.x and Netware 6.5 SP6.
2) Determine the version of eDirectory I have on each server prior to applying Netware 6.5 Service Pack 6. To do this, on the system console type version
3) Apply the appropriate patches, reboot, and run a dsrepair on the master just to be safe once eDirectory has been patched. TID 3426981 appears to be a living document that keeps up with all the changes in the eDirectory updates.
4) Backup eDirectory using dsbk before attempting any patching or upgrades
Starting June 12, 2007, Windows 2003 Service Pack 2 (SP2) will be automatically installed on Windows 2003 servers that have Automatic Update (AU) setup to download and install critical updates without administrator approval. This service pack is also installed when visiting Microsoft Update or Windows Update and automatically updating your system.
A toolkit is available that will temporarily block SP2 until March 13, 2008. Hopefully this will be sufficient time forMicrosoft to resolve the issues that stem from this patch. More information is available from the toolkit’s FAQ.
You may want to educate yourself on the potential issues SP2 can cause, especially if you are on Windows 2003 Small Business Server (SBS).