In the below table I described all of the registry locations I know which programs are using to start automatically with Windows:

Some information in the above table has been taken from this forum: Registry AutoStart Locations

But first let think why the old os cannot successfully boot on the new hardware. The problem lies in two places (or at least in one of them). First is the controller of the system disk – if the controller in the new motherboard comes from other vendor or is simply incompatible with the old controller (for examle the old one was Intel IDE and the new is VIA IDE), then the os does not have the right device driver for it and as the result it cannot access the hard drive during boot resulting in BSOD. The second lies in the processor architecture (but only if the new processor is from other vendor, for example the old one was from Intel and the new one comes from AMD).

To cope with the problem with device driver for disk controller you have to have a Live CD or bootable USB flash (with BartPE, VistaPE, etc.) in which you can access the system partition and the registry of the installed system. You will have then manually place the right driver for the new disk controller in the “%systemroot%\system32\drivers” folder and manually add or edit the registry to make the driver being loaded with the system (the drivers are being represented as services in the following registry key: HKLM\System\CurrentControlSet\Services).

When you will be fine with the driver for the hard disk controller, then you need to ensure that the IntelPPM service is disabled  (in the registry the start value must be set to 4). Without disabling it, when the new processor comes not from Intel, you will end up with BSOD as well.

This is not a detailed explanation of what to do exactly but it shows the way you shall go if you don’t want to reinstall the whole operating system after changing your hardware like motherboard, disk controller or processor.

The problem with such operation is that after restoring for example 20GB partition image to a partition which has 40GB, you will see, that the file system says that there is only 20GB of total partition’s space. This is caused due to old partition size information saved inside internal filesystem’s structures, which was made during the format of the partition on the original drive. Fortunately, the DISKPART utility built in Windows XP and newer systems can fix that problem. To do that follow the following steps after you restore the image to the new, reater partition:

1. Launch the diskpart command line utility.
2. Execute “select volume <number>” command, where “<number>” is a number of the volume containing the restored partition image (the list of all volumes and their numbers can be retrieved by executing “list volume” command).
3. Execute “extend filesystem” command.
4. And this is all – now exit the diskpart utility by executing “exit” command and the system will correctly see the real partition size.

Thanks to this tip you can use programs like SelfImage not only for making backups but also for moving entire partitions (including system partitions) to other hard drives even, when they size do not match.

The solution to such problems is quite easy – you only have to add /usepmtimer switch to your server’s boot.ini file and restart the virtual server. This will cause a different approach during time measurement and will fix mentioned problems.

To fix this irritating behavior clearing the dnscache will not always work. The best way to cope with this problem is to stop DnsCache service – after doing that every time you try access any network resource by its name, the DNS name query will be passed directly to your DNS servers omitting your local cache.

EDIT:

After some time I noticed one more problem with DNS especially when using VPNs established using RRAS. Simply the names were not being resolved by DNS servers provided by RRAS but they were trying to be resolved by DNS servers outside of VPN. This prevented accessing VPN network resources using names. The problem can be fixed by following the following steps:

1. Go to Network Connections in Control Panel.
2. Go to Menu: Advanced -> Advanced Settings -> Adapters & Bindings
3. Move DialUp connections to the top of the list.
4. Save changes by clisking OK button.
5. In Windows XP & 2k also follow the instructions described under the following link: http://support.microsoft.com/default.aspx?scid=kb;en-us;311218
6. Reboot your computer.

After performing the above operations you should not have any DNS issues when using VPNs on your computer.

Mentioned problem sometimes arises after some malware installation – the disinfection not always repairs that problem automatically.

The reason why MS Exchange does not register mentioned library by itself during the installation is unknown for me. However I noticed, that MS Exchange installers are written is such a way, so the administrators can demonstrate their knowledge and skills <ironic> before the MS Exchange product can start fully working.

Fortunately, I found a way to prevent the system from reading the autorun.inf file at all resulting in completely disabled autorun feature. It is done by creating a new key in the registry. The key that must be created is:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\IniFileMapping\Autorun.inf
with its default value set to:SYS:DoesNotExist

After creating mentioned key and restarting the shell by killing explorer.exe process, logging out or rebooting, the autorun feature in the whole system will be completely disabled allowing everyone to plug any portable devices without worrying about malware anymore.

However, there is a great tool called “TweakUI” (created by Microsoft), which can change specific Access Lists in the registry, so we can give anyone we want the right to share folders or printers. To make this happen you must do the following steps:

1. Download and install TweakUI (you can get it from here: http://www.microsoft.com/windowsxp/downloads/powertoys/xppowertoys.mspx)
2. Launch it and go to “Access Control” tab.
3. Now give the same rights for the users or groups you want to be able to share folders, like they are set for “Power  Users” in the following categories:
   • Manage file/print server connections
   • Manage file shares
   • Manage print shares
4. Apply the changes and reboot the system.

From now, the specified in step 3 users or groups will have the right to share folders. It is wise, to create a group called for example “Share Creators”, give it the mentioned earlier rights and put all the users we want to share folders into that group.