Hello,
To start, this will be a rather lengthy post. I'll include a short summary at the bottom of this message.
Over the last month, during our semester break maintenance period for our classrooms and computer labs, we have been deploying images to our workstations. This is our current standard practice. Our workstations are configured with a standard base image, which we sysprep then distribute to other technicians who then add their applications and settings. The resultant images then are gathered (and sysprepped) and deployed to the workstations. In all cases, the images are set to DHCP during building and sysprepping, and sysprep sets them to DHCP during setup.
During this past maintenance period, there have been many complaints among the technicians deploying their images. The one complaint I have been trying to address is about failing Configuration tasks.
Our client workstations, in most cases, are configured with static IP addresses (along with the added requirements, like subnet mask, gateway, DNS server list, etc.). During our deployments, we have seen Configuration tasks apply everything successfully, apply hostname and workgroup only, or apply nothing. This Configuration task problem seems to be affecting everyone. The Configuration tasks seem to succeed 95% of the time when deploying a configuration to a DHCP-enabled workstation. The Configuration task seems to fail 100% of the time when changing the workstation object in GSS back to DHCP, then applying this configuration to a static addressed workstation. Hostname and workgroup changes, however, are applied. When applying a static IP configuration from GSS to a static addressed workstation, there are sometimes inconsistencies in the gateway and DNS server list that are applied on the workstation.
Every attempted task returns a "Successful" result from the GSS task log.
I began troubleshooting and attempting to reproduce the results that were reported. I set up a GSS 2.5.1 console of my own to validate the problem. So far, I've been able to reproduce it.
The steps I have taken are:
- Deploy our base image to a model workstation.
- Install the GHOST Console Client to the model workstation.
- Verify that GSS bears a Workstation object, and that object is configured for DHCP.
- Change the configuration from DHCP to static in GSS.
- Apply the configuration by a "Configuration" task from GSS to the model workstation.
- Watch WinPE (and PC-DOS) successfully apply the configuration and reboot.
- Examine the resultant configuration on the model workstation (usually successful).
- Apply a DHCP configuration from GSS to the workstation object.
- Apply the configuration by a "Configuration" task from GSS to the model workstation.
- Watch WinPE (and PC-DOS) successfully apply the configuration and reboot.
- Examine the resultant configuration on the model workstation (usually NOT successful).*
*The IP configuration may not have changed, but usually the hostname has.
Now, several changes have been made to our base image, namely from Kaspersky Anti-Virus 6 (KAV 6) to Kaspersky Endpoint Security 8 (KES 8). This change was, for the most part, untested. It was my first suspect since the Configuration problem seemed to coincide with the introduction of KES 8. I decided that it would be a good idea to manually apply the configuration in Windows PE myself using GHconfig32.exe and a configuration file (GHREGUPD.REG). I also chose to attempt this configuration on a brand-new Windows 7 installation without anti-virus. These changes yielded the same result as the above scenario.
When manually testing the application of the GHREGUPD.REG configuration I used the X:\Ghost folder to contain the file. I used the following commands to apply the GHREGUPD.REG configuration file on my test workstations (1.2 is my [Disk.Partition] target):
ghconfig32.exe /w=1.2:\Windows /c=X:\ghost
This performed as expected when applying a static address configuration file on both the base image (with KES 8) and the fresh Windows 7 installation. The DHCP-enabled configuration file did not yield the same result. It only applied the hostname changes contained within the GHREGUPD.REG file and left the static IP address in place.
Here are the contents of my configuration files. The static configuration:
CONFIG_COMMANDS COMPUTERNAME = "THISISATEST2" "THISISATEST2" DNSHOST = "thisisatest2" "thisisatest2" WORKGROUP = "NEW" "NEW" IPADDRESS = "192.168.1.2" "192.168.1.2" SUBNETMASK = "255.255.255.0" "255.255.255.0" DEFAULTGATEWAY = "192.168.1.1" "192.168.1.1" DNSSERVER = "192.168.1.254,192.168.1.253" "192.168.1.254,192.168.1.253" DNSDOMAIN = "mycorp.com" "mycorp.com" SYSPREPMINISETUP = 0 0 END_CONFIG_COMMANDS
And the DHCP configuration:
CONFIG_COMMANDS COMPUTERNAME = "THISISATEST" "THISISATEST" DNSHOST = "thisisatest" "thisisatest" WORKGROUP = "DINGUS" "DINGUS" IPADDRESS = "0.0.0.0" "0.0.0.0" SYSPREPMINISETUP = 0 0 END_CONFIG_COMMANDS
And finally, the output from GHConfig32.exe after executing the command (with both configuration files):
Windows: [C:] 1.2:\windows
<blank line>
I then reboot the workstation with either "exit" or "X:\ghost\ghreboot.bat" (both yield identical results when used).
If you took the time to read this post, thank you.
Has anyone else experiened this sort of problem?
SUMMARY
- GSS 2.5.1 (11.5.1.2266).
- Windows 7 SP1 and Windows 7.
- Image sysprepped, configured for DHCP.
- Configuration push from GSS console fails to revert machines from static to DHCP address.
- Most DHCP to static address configuration pushes succeed.
- Config files (GHREGUPD.REG) files look fine.
- Manual application of GHREGUPD.REG via GHConfig32.exe is broken, too. Not a network problem.
- Antivirus is not the problem.
- Windows 7 with no changes or updates behaves the same as the base image.