Disabling computer account creation in RIS

It would be nice if we had the option to deploy RIS-based images as either domain-joined or free-standing systems. As it stands, default configuration forces all imaged systems to have a pre-staged computer account. Since most imaging jobs are scheduled for eventual deletion, we run into a real problem with computer that we want to keep joined.

One possible work-around is to change the “Image Type” variable associated with the image (I believe this info is located in the .SIF file. I tried this once before when attempting to generate a bootable WinPE instance on our RIS server… I think it worked for WinPE, but I am not sure if it will work for standard images. It is worth a shot. Details taken from:


Here is the text of the newsgroup posting:

Normally, you would modify the RISSTNRD.SIF file for that Windows PE image
to change the “ImageType” entry from “ImageType=Flat” to “ImageType=WinPE”.
This causes RIS to no longer create the computer account (to prevent “AD
clutter”), which OSD is not going to use anyway. When making this change,
the Windows PE image will move from the “images” list to the “Tools” menu,
so you have to have the tools menu enabled via GPO to see it. For more
information on this, see the “Zero Touch Installation Deployment Feature
Team Guide” in the Solution Accelerator for Business Desktop Deployment
Enterprise Edition (http://www.microsoft.com/desktopdeployment).

I have downloaded the Solution Accelerator that is referenced, and will have a look though the “ZTI” section to see if it is any further help.

SAV 10 installer, redux

What a pain! Our testers still report problems with SAV 10.0.1 installers. High CPU, disk thrashing, scheduled scans kicking off without permission…

Several fixes. First off, I generated a fancy new install script:

ECHO – Symantec Antivirus installation script for the University of Vermont

  • ECHO – version 2.1, by JGM, 2005-10-17
    ECHO – This Window will close automatically when installation has completed.
    REM Script can be altered to allow for either managed or unmanaged client installations.
    REM For managed installs, UN-comment the “goto endFirewall” line below, and uncomment the appropriate “setup” command line.
    REM For unmanaged installs, COMMENT OUT the “goto endFirewall” line below, and uncomment the appropriate “setup” command line.

    REM If performing an unmanaged AntiVirus client installation, uncomment the following line:
    REM GOTO endFirewall

    REM Determine if host is running a Windows XP build:
    set OSVer=notXP
    ver | find /i “xp” && set OSVer=XP
    IF NOT %OSVer%==XP GOTO unsupported ELSE goto spLevel

    REM Determines Service Pack Version via registry query:
    set SPVer=0
    REM systeminfo |find “Service Pack 1″ && set SPVer=1
    REM systeminfo |find “Service Pack 2″ && set SPVer=2
    reg QUERY HKLM\SYSTEM\CurrentControlSet\Control\Windows /v CSDVersion | find “0×200″ && set SPVer=2
    IF NOT %SPVer%==2 GOTO unsupported ELSE GOTO addRules

    REM Adds firewall exceptions for Windows XP SP2 hosts:
    ECHO – You have Windows XP Service Pack 2! Let’s Go…
    ECHO – Please wait while firewall exception rules are added…
    ECHO Adding exception for Symantec Realtime Virus Scan to allow managmenet of SAV Client
    netsh firewall add portopening protocol = UDP port = 2967 name = “Symantec RTVScan” mode = ENABLE scope = CUSTOM addresses = LocalSubnet,, profile = ALL
    netsh firewall add portopening protocol = UDP port = 38293 name = “Intel PDS (Symantec AV)” mode = ENABLE scope = CUSTOM addresses = LocalSubnet,, profile = ALL
    IF NOT errorlevel 1 (
    ECHO All firewall rules added successfully.
    ) ELSE (
    GOTO failRuleAdd
    GOTO endFirewall

    ECHO Your system is not running XP with Service Pack 2.
    ECHO You do not need firewall exceptions added to your system.
    GOTO endFirewall

    REM If installing an unmanaged AntiVirus client, installation may begin here.
    ECHO Altering registry to remove and prevent automatic system scans…
    reg import RemoveStartScan.reg
    IF NOT errorlevel 1 (
    ECHO Registry settings imported successfully.
    ) ELSE (
    GOTO failRSS
    ECHO Deleting log files from previous installations…
    del /f /q “%ALLUSERSPROFILE%\Application Data\Symantec\Symantec AntiVirus Corporate Edition\7.5\Logs\*.*”
    IF NOT errorlevel 1 (
    ECHO Symantec AV Log files successfully deleted.
    ) ELSE (
    ECHO No previous Symantec AV log files needed to be deleted.
    del /f /q “%ALLUSERSPROFILE%\Application Data\Symantec\Norton AntiVirus Corporate Edition\7.5\Logs\*.*”
    IF NOT errorlevel 1 (
    ECHO Norton 200/XP AV Log files successfully deleted.
    ) ELSE (
    ECHO No previous Windows 2000/XP Norton AV log files needed to be deleted.
    del /f /q “%PrograFiles%\Norton AntiVirus\Logs\*.*”
    IF NOT errorlevel 1 (
    ECHO Windows 9x Log files successfully deleted.
    ) ELSE (
    ECHO No previous Windows 9x Norton AV log files needed to be deleted.
    ECHO Proceeding with SAV install…
    REM One of the following two “setup” lines MUST BE COMMENTED OUT!
    REM installation string for an UNMANAGED client install (intended for off-campus users):
    REM setup /s /qn /V”/qr REMOVE=Pop3Smtp,NotesSnapin ADDLOCAL=SAVMain,SAVUI,SAVHelp,QClient,OutlookSnapin NETWORKTYPE=2 RUNLIVEUPDATE=1″
    REM **This does not work!*** IF NOT errorlevel 1 GOTO setupFail
    REM installation string for a MANAGED client install (intended for systems that are frequently on-campus):
    setup /s /qn /V”/qr REMOVE=Pop3Smtp,NotesSnapin ADDLOCAL=SAVMain,SAVUI,SAVHelp,QClient,OutlookSnapin NETWORKTYPE=1 SERVERNAME=NORTON2 RUNLIVEUPDATE=1″
    REM **This does not work!*** IF NOT errorlevel 1 GOTO setupFail
    ECHO Product setup complete,
    ECHO Now attempting registry alterations to prevent Definitions scans…
    reg import DefwatchQSOff.reg
    IF NOT errorlevel 1 (
    ECHO Registry settings imported successfully.
    ) ELSE (
    GOTO end

    ECHO Firewall exceptions script failed!
    ECHO Symantec AntiVirus NOT INSTALLED.
    ECHO Take your system to Walk-in help.
    GOTO end

    ECHO “RemoveStartScan” registry import failed!
    ECHO Symantec AntiVirus NOT INSTALLED.
    ECHO Take your system to Walk-in help.
    GOTO end

    ECHO Oh No! Symantec setup program failed to complete!
    ECHO Symantec AntiVirus NOT INSTALLED.
    ECHO Take your system to Walk-in help.
    GOTO end

    ECHO “DefwatchQSOff” registry import failed,
    ECHO but Symantec AntiVirus has been installed.
    ECHO If you experience major system performance degradation,
    ECHO please take your system to Walk-in help.
    GOTO end


  • Changes from previous scripts are:

    1. integration of managed and unmanaged installer scripts in same file – change the comments to change the install method.
    2. attempts at error capturing using IF/Then/Goto
    3. integration of script into one file (sans .reg import files)
    4. added DefwatchQSOff.reg import to the script, moved to end of script
    5. Now using “removestartscan.reg” to kill startup scans… seems to work.
    6. not allowing installation of POP3SMTP plugin
    7. using “setup.exe” with command line options, rather than msiexec. This avoids the need to create separate installers for upgrade vs. new install
    8. Integrated patch into the installer (by extracting original .MSI to an “administrative install point”, then using the msiexec patch commands on the admin install point).

    RIS Server Setup notes

    I had some fun setting up RIS on the newly repurposed server “SYSIMG1″.

    One issue is that copying all of the RIS Images from the current production “RISPRIME” would not complete… I ran out of space on the target volume which is the same size as the source volume. Why? Because RIS runs the “groveler.exe” service to create hardlinks for duplicate files in RIS images. My file copy utilities just copy the hardlinks as separate files, and thus I run out of space.

    Presumably forcing the groveler to startup on the target volume will free up the space needed to complete the transfers… but how to do this? Groveler.exe has no command line support, and has a hard-configured schedule on which it runs (2am or some such). I want it to run now!.

    Some searching reveals the following KB article:

    I will see if I can find this grovctrl.exe utility of legend. Sounds like just what I need.

    Also found some good docs at MIT:
    and berkeley:

    ADS Imaging – project catalyst

    Catalyst needs us to install eight new servers for them this week. Although it will probably take longer, I have decided to take a stab at using Microsoft ADS (automated deployment services) to roll out the systems.


    1. Install ADS on server “sysimg1″ (reusing the host “castor” from the NetWare days). Select “install MSDE engine locally” and “create self-signed certificate” options. Did not select PXE boot server option… will need to do this later. Also, created share “images” on the root of the c: drive” (note that local storage is rather limited… this may become an issue as time passes).
    2. Created WinPE boot CD rom with ADS support, using ADS documentation as a guide. See notes in this blog in on generating WinPE images.
    3. Created reference system:
      • install MS Office 2003 with SP1, full install from \\files\mca. Ran LISTool from the office 2003 resource kit to move the installation source to the C: drive where it will be imaged properly.
      • – NOTE: did not do this on subsequent system configurations!

      • Install Networker client version 7.2.1, using “Change Journal Manger” option on all local volumes (default settings… saved installer to \\files\software\Server Resources\networker).
      • Install ActiveState ActivePERL. Latest version from activestate.com (saved to \\files\software\active perl).
      • Install Dell OpenManage Server Administrator – v4.4, with sp1 patch (from \\files\software\server resources\dell).
      • Install SSH communication Security SSH client – latest version, default settings.
      • Install 2003 server resource kit, support tools, “adminpak.msi” for 2003 with sp1.
      • Re-install Intel ProSet utility, using “modify” MSI option, then adding all components (advanced services, Intel WMI agent) – allows for NIC teaming.
      • Install GVim and Notepad++ text editors (deselect “use as default html viewer” for Notepad++).
      • Install “runtime” version of Oracle 10g client v10.2.0.1 to the “c” drive. Added tnsnames.ora file provided by catalyst staff to the %oracle_home%\network\admin directory. Per instructions from Nancy Snow, add “TNS_ADMIN” system environment variable pointing to the same directory containing the TNSNAMES.ora file.
      • add “psadm” CAMPUS directory group to local administrators group.
      • create c:\sysprep directory. Add sysprep.exe, setupcl.exe from Server 2003 sp1 “deploy.cab” file (support tools directory on the 2003 cd). copy sample sysprep.inf file from “\\sysimg\c$\program files\microsoft ads\samples\sysprep” directory. Add minor tweaks, copy back to source directory.
      • run chkdsk and defrag a few times for good measure.
    4. run “sysprep /reboot” on the reference system. Boot to WinPE CD.
    5. from the PE console, cd to the “tools” directory. Run:

      imgdeploy /capture /p c: d:\.img “”

      Then “exit” when the image is complete.
      Note:networking still not working in PE image. Aargh! Well, I guess I will just have to upload the image manually.

    Windows PE

    Since we are now on Campus Agreement, we have access to “Windows PE”, the Microsoft bootable 32-bit OS for system installation and maintenance.

    Lots of work to get everything going. Let us start with a 2k3-ee WinPE install:
    note: turns out my 2k3ee sources are corrupted… bummer! Switched to SE, since it really makes no difference…

    1. Download Windows PE, 2005 edtion from microsoft licensing site (Password ID and login info provided by Nicole Chittenden, former manager of CA at UVM).
    2. Extract PE package. In my case, to F:\WinPE
    3. Extract Server 2k3 EE to local hard drive – slipstream SP1 into the directory
    4. at shell, cd to F:\winpe\winpe, run

      mkimg.cmd d:\2k3-ee-sp1 c:\winpe-2k3-ee

      (this builds a WinPE installation using the 2k3 server source to the directory specified.)

    5. Now, add Microsoft ADS support files to the WinPE image: Add the files Adssupport.dll, Imglib.dll, and Imgdeploy.exe to a directory of the Windows PE build folder. These files can be found in the \Program Files\Microsoft ADS\Bin and C:\Program Files\Microsoft ADS\nbs\repository\DeploymentAgent directories where the ADS imaging tools are installed. (note that the MS documentation is a bit off on the location of these files).
    6. note: If networking will be required when booting to a subnet without DHCP support, a static address will need to be configured in the winbom.ini files of the WinPE image. I added the following to assist in the generation of the Catalyst images:

      Gateway =
      IPConfig =
      StartNet = Yes
      SubnetMask =
      WinPEFirewall = On

    7. Finally, create an ISO to burn to CD. Again at the F:\winpe\winpe shell, run:

      oscdimg -betfsboot.com -n d:\winpe-2k3-ee d:\winpex86-2k3-ee.iso

    Now let’s build a WinPE for XP Pro.

    1. Extract XP Pro CD (SP2 integrated) files to the local hard drive.
    2. at shell, cd to F:\winpe\winpe, run

      mkimg.cmd d:\xppro-sp2 c:\winpe-xppro-sp2

      (this builds a WinPE installation using the XP Pro source to the directory specified.)

    3. Note that for XP, we will want to perform the additional step of adding some NIC drivers. We have a bunch of these alrady available on our RIS server. Start by copying our current XP NIC drivers from the production RIS server to a local directory (in our case, D:\drivers-xp):


      Again at the F:\WinPE\WinPE shell, perform the following:

      drvinst.exe /inf:d:\drivers-xp d:\Winpe-xppro-sp2

      Note that this procedure will only work for non-PNP drivers, UNLESS we do a special WinPE build enabling it (mkimg /PNP)

    4. Finally, create an ISO to burn to CD. Again at the F:\winpe\winpe shell, run:

      oscdimg -betfsboot.com -n d:\winpe-xppro-sp2 d:\winpex86-xppro-sp2.iso

    Norton1 LiveUpdate server complaints

    LiveUpdate complaints from the end-users… cannot run LiveUpdate, LiveUpdate logs indicate a specific file was “unavailable on the server”.

    FTP into Norton1.uvm.edu does reveal that the file is not actually there. The quick fix here is to resynch the LiveUpdate directory from SYmantec. To do this:

    1. On Norton1, Launch “LiveUpdate Administration Utility”.
    2. Go to Tools>Options, then select “Retrieve new and previously downloaded updates”, then “ok”.
    3. Click “retrieve”, wait for the process to complete.
    4. Change the previously set option back to “New updates only”.

    Now test out LiveUpdate to see if the missing file has been restored.

    Frank's Deep Thought of the Day

    Men die earlier than women because they want to.

    Changing WX Client Modes

    WebXtender has two modes: Interactive (IRC), or “Thin Client”. Interactive requires IE 6 with ActiveX controls, wheras “Thin” does not, but has fewer features.

    To set the mode for users, you must enter the “User Profile Administrator” program that installs with XS Admin. You can change the global default, and/or the default for specific users (but not for Groups???!!!). Without further configuration, this option becomes fixed, and the user cannot change it.

    However, in App Gen (part of a Full ApplicationXtender install), you can set a global option per-user or per-group called “Configure WS”. Once set, this allows the user to change ALL WebXtender user-configurable options, including the client mode.

    Note: Setting this option in AppGen does not enable it for the user automatically! You must restart the WX service in order for the change to take effect! AARGH! (Recommended approach is to run the “Component Setup Wizard” which ships with XS Admin).

    Oracle Instant Client, continued

    To simplify installation of the OC, I wrapped the files into a MSI using “Advanced Installer” v2.6.4 from Caphyon Software.

    To accomplish this, I just needed to follow the previously documented manual installation routine, and take note of what changed on the system (specifically, I had a look at the REG text files generated by the ODBC installation script).
    Advanced Installer lets to specify source files from ANY location, to be installed to a specified Program Files target. You also can specify Environment variables and Registry settings that you want performed during the install.

    I just shipped the Install Directory to “University of Vermont\Oracle 10g Client”, and added an “admin” subdirectory for the TNSNAMES.ORA file. Then I set the PATH, SQLPath, and TNS_Admin environment variables. Finally, I specified the required ODBC registry changes, and built the MSI.

    Since doing the build, a new version of OC 10g Instant Client has become available (v10.1.0.4). I have updated the installer to use these files instead. Making this change is fairly simple. All you have to do is open the original Adv Installer package specification file (.AIP), take note of the location of the source files, then drop the updated files into that location. If there are any new files, or files that are no longer present, you need to update the AIP to reflect these changes. Change the package version number, then rebuild… easy.

    Packaging ApplicationXtender

    After some fine head-banging, I have figured out how to package the ApplicationXtender 5.25 .MSP (patch) file into the original 5.20 installer. We just need to follow the standard “administrative installation point” routine:

    1. At the command line, go to the AX 5.20 installation directory.
    2. Run
      msiexec /a AxSetup.msi TARGETDIR=[working directory]
    3. Assuming the MSP file is in the same directory, run
      "msiexec /p /a [working directory]\AxSetup.msi"
    4. Now just zip the working directory into a single file.

    We do have some other options that may help with deployment:

    1. The “XSCM.Config” file from “\Documents and Settings\All Users” into the final archive directory, along with a script that drops this file into place on the target system. This will save installation staff the need to locate the setup file on first run of the application
    2. The install directory can be added to a self-extracting zip, which calls the SETUP.EXE.
    3. SETUP.EXE has command-line support, documented in the AX Installation guide. Essentially, we would run
      SETUP MsiExec.exe /i "AxSetup.msi" /QB INSTALLLEVEL=[install_level]
      where [install_level] is a number from 1 to 3. 1=Retrieval install, 2=Scan, and 3=admin install.