Computer Stuff

The “unauthenticated network” in Vista, which means RDP and many other things do not work (basically, it has broke kerberos) was in my case due to two computers having the same name.

I have no idea why I was allowed to join a Windows 7 laptop called Julian-PC to the domain when there was already a Vista desktop called Julian-PC on the domain.

There were no warnings of duplicate names on the network, but adding a new computer to the domain with the same name as an existing computer caused the existing computer’s Computer/Machine Account to be overwritten in active directory, and so the machine was no longer a working domain member and kerberos/authentication was broken. We were seeing “cds.local 2: unauthenticated network” instead of just “cds.local”.

Hope this helps others.

Many people know that there is a file called SYSTEM.SAV under \windows\system32\config, along with all the other registry hive files. Most people also know that this is a backup copy of the SYSTEM registry hive, from some time in the past – usually years ago, but when does this file become extremely important and useful, and when and why was it created ?

I thought I would write this blog post to describe some observed behaviour / patterns and how this file needs to be utilised for repairing some sometimes seen damage on XP computers.

The problem I sometimes run into is: Corrupt file system or Windows installation. A repair install is undertaken. After the text-mode part of the re-install, when the GUI starts, you are prompted with message “The file ‘Asms’ on Windows XP Professional CD-ROM is needed. Type the path where the file is located, and then click OK.”

What is interesting here is that the Path in which setup is looking for the installation files is something like \\GLOBALROOT\CDROM\Blah. If you change it to D:\i386 this does not help.

So we hit CTRL-F10 for a command-prompt, then we type sysdm.cpl to fire up system properties, and we look in Device Manager. We can see that the CD-ROM device is broken. This is because of the common broken Upper / Lower filters problem. The cure for this is to enter the registry, under HKLM\System\CCS\Control\Class\4D36E965… (the one that says DVD/CD-ROM drives on the right), and remove the UpperFilters or LowerFilters (see http://support.microsoft.com/kb/314060), then reboot.

So we do the above, reboot (nicely, by clicking cancel on the “asms” prompt, or ending setup.exe through taskmgr). After the reboot, setup will automatically restart from the same point, and we hope that the CDROM drive will be working and setup will be able to find the installation files.

But it doesn’t work! We are back where we started! We hit CTRL-F10 and check in device manager, and in the registry, and the UpperFilters or LowerFilters are back! It’s like we’ve been working on a temporary copy of the registry and not the proper registry! Any changes we made were lost when we rebooted!

Well this is what SYSTEM.SAV is all about. It seems that during the in-place upgrade / repair install, Setup is moving the existing SYSTEM registry to SYSTEM.SAV, and it is dumping that into a new SYSTEM each time it is started, or something to that effect.

So, if we want to make registry changes during setup that will be effective upon reboot/restart of setup, we need to make the changes in SYSTEM.SAV. Go into regedit (CTRL-F10 -> regedit). File -> Load Hive. Find the file SYSTEM.SAV in \windows\system32\config, load it, enter “system.sav” for the name. It will show up under that name. Find the UpperFilters or LowerFilters or whatever you need to modify under the system.sav part that now appears in regedit, make the changes, then highlight system.sav again and go to File -> Unload hive.

Reboot, let setup restart, and watch it work*

*You may need to remove the CD-ROM drive from Device Manager (CTRL-F10 -> sysdm.cpl) and then “Scan for hardware changes”..

So now you understand firstly what system.sav is, you also know when it is from and why this old file is there, and have a practical example of why this is useful to know.

Accounts Pro uses SQL DMO, which is depreciated (other components use SMO and are OK), so if using SQL Server 2008 (R2), then download and install Microsoft SQL Server 2005 Backward Compatibility Components onto the Workstations.
This tool (Diagnostics-v2.exe) can be useful for repairing Integration settings, but it will enter an incorrect path for Accounts Pro, so fix that afterwards with the Configuration.exe located at:
C:\Program Files\Common Files\Digita Shared\Integration\v2.00\Configuration.exe.
Make sure location/path is correct, for the various apps.