Invalid Boot.ini, loading from C:\Windows

The problem was caused due to a corrupted boot.ini file which is usually located in the C drive. Since I had a copy of XP Home I tried to rebuild the boot.ini as per the instructions below.

1. Insert the Microsoft Windows XP CD into the computer. Note: If you have a system recovery CD or restore CD (not a Microsoft CD) these steps will likely not work for your computer.
2. Reboot the computer with the CD and press any key when prompted to press any key to boot from the CD. If you do not receive this prompt and/or are not able to boot from the CD see document CH000217.
3. Once in the Microsoft Setup menu press R to open the recovery console.
4. Select the operating system you wish to use; if you only have Windows XP on the computer you will only have one prompt.
5. Once prompted for the password enter the Admin password and press enter.
6. Once at the command prompt type bootcfg /rebuild to start the rebuild process.
7. The rebuild process will step you through a number of steps depending upon how many operating systems you have on the computer and how the computer is setup. Below is a listing of the common steps you are likely going to encounter.
• Prompt for the identified versions of Windows installed. When you receive this prompt press Y if the bootcfg command properly identified each of the Windows operating systems installed on the computer. It is important to realize this command will only detect Windows XP, Windows 2000, and Windows NT installations.
• Prompt to enter the load identifier. This is the name of the operating system for the boot.ini. For example, Microsoft Windows XP Home users would enter Microsoft Windows XP Home edition.
• Prompt to Enter OS load options. When this prompt is received type /fastdetect to automatically detect the available options.
8. Once you have completed all the available options in the rebuild and are back at the prompt type exit to reboot the computer.

See Microsoft KB289022 for more info on boot.ini.

net stop bits
net stop wuauserv
regsvr32 /u wuaueng.dll /s
del /f /s /q %windir%\SoftwareDistribution\*.*
del /f /s /q %windir%\windowsupdate.log
regsvr32 wuaueng.dll /s
net start bits
net start wuauserv
wuauclt.exe /resetauthorization /detectnow

This did not solve the issue for me. I turned out that my WSUS server did not mark the old IMF update as declined. Once the old update’s status was changed to declined the update cycle was stopped dead in its tracks.

Turns out it was running on an old monitoring PC I had used years before that was still powered on. Since I still use it for a couple of other monitoring apps I couldn’t just turn it off. As a temp fix I stopped the service and set it to disabled. Now the PRTG VM started up and began collecting data once again.

As the PRTG uninstaller did not remove the PRTG service from the old monitoring PC I still needed a way to pitch it even though I had disabled it. A quick search turned up a couple of options, the easy way and the slightly more difficult way.

The Easy Way:

sc delete “service_name”

In my case the command was:
sc delete PRTGService

The Slightly More Difficult Way:

**Dislaimer: This process involves working in the Windows Registry. Before deleting any file please make a backup in case of borking your system.

Run Regedit

Find the registry entry “HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services”

Look for the service there and delete it.

Here is what I did to get my clients checking in again.

Check the folder permissions on the SelfUpdate directory, located at C:\Program Files\Update Service\SelfUpdate. Make sure the permissions like this;

In my case the IUSR_ComputerName permission was missing.

After adding the correct permissions I looked for the re-installation msi, Selfupdate.msi. The only problem is that the SelfUpdate re-installation msi was not found on my WSUS server. Turns out in the recent WSUS update to 3.1 this installer can become corrupted and not installed on the server.

To get the Virtual Directory back I would have to install it by hand. Here are the settings you need to create it;

Open Internet Information Services (IIS) Manager. Right click on the “Default Web Site” and choose;

• New
• Virtual Directory…
• It started the VD Creation Wizard
• Alias = SelfUpdate
• Path = C:\Program Files\Update Services\SelfUpdate
• Finish the wizard.
• Right click on the newly SelfUpdate and choose Permissions.
• I added “Authenticated Users” and gave them the default rights:
• Read & Execute
• List Folder Contents
• Read

After completing these steps I ran “wuauclt /detectnow” on each of my servers. I left the workstations to check in on their own.

Within 12 hours the number of missing clients had gone from nearly 200 to less than 50. Once everyone logs in on Monday morning this number should dwindle to nothing.

I tried for most of Friday to get my keys but was unable to get past the green circle of death. Today the process was painless and carefree.

I haven’t had the time to install it yet, but look forward to doing so and seeing if the hype meets expectations.

Note: While completing this process your WSS site will be offline to your users.

1. Shutdown all Windows Sharepoint services & IIS Admin service: This will ensure that there are no locks on the files you need to move.
2. Open a cmd prompt and cd to C:\Program Files\Microsoft SQL Server\90\Tools\binn
3. Enter sqlcmd -S \\.\pipe\mssql$microsoft##ssee\sql\query -E: This starts the Microsoft SQL Server 2005 Command Line Query Utility
4. Enter the following commands to view the available databases & hit Enter after each:
• SELECT name from sysdatabases
• GO

You should see a number of DBs, move the following 4 databases (GUID’s may be different):

• SharePoint_Config_c464b7ce-59ef-4820-9f75-f46a0937c08e
• SharePoint_AdminContent_451452bf-9dc0-40c9-be18-14f14bc23007
• WSS_Search_NETSERVER_86a140c5958d4a5d97c8c2cbee745424
• WSS_Content
5. Enter the following commands & hit Enter after each line. Repeat for each database.
   • EXEC sp_detach_db @dbname = ‘Content_Database_name’

   • GO
6. Move the databases to their new location. They can be found in C:\Windows\SSQL\Data\.mdf and _log.ldf
7. After the files have been moved run the following commands (Make sure to change the itialic sections to your specifics):
• EXEC sp_attach_db @dbname = ‘Content_Database_name‘, @filename1 = ‘drive:\path\Data\.mdf’, @filename2 = ‘drive:\path\Data \_log.ldf’
• Go
8. Repeat step 7 for each database you moved.
9. Restart IIS Admin services and all Windows Sharepoint services
10. Ensure your Sharepoint site is working

If this is done before you build your site it will take no time at all to move the DBs to the new location.

Desktop Authority and registry settings to the rescue.

I searched Google for the location of the registry key used to set the zones and came up with:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\Domains\thedomainname.com\thesubdomain

Type: RED_DWORD
Value: http
Data: 1

I added my required site as a DWORD value in to DA, which can been seen below:

I then applied this policy to my users and the next time they log in the setting will be applied for them.

They registry key to use is:

[HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main]
“Start Page”=”http://www.howtogeek.com/”

Here is a screen cap of the DA settings I used:

After replicating this to our domain controllers each user who logs in will have their homepage set to http://sharepoint/.

NOTE: The above procedure was used because my GPO for setting the default homepage was not working on these HP desktops.

Back in early August a user reported that they could not print to a specific tray (manual feed) on a HP Laser Jet 4350.  Deleting the printer did nothing.  Restarting didn't clear it up.  Logging in as a different user didn't work.  Printing to the manual tray from other PCs work fine.  It was just this one PC.  This is where I started sharpening my machete and called up another IT pro and picked his brain.  He had only seen this type of behavior once before.  He suggested removing all instances of this printer from the registry. 

So in I went.  I fired up regedit, entered the name of the printer in the search field and hit enter.  I had never done this kind of hacking of the registry before.  I had removed many keys, added even more, but never had I gone in and deleted large branches before.  Not surprisingly there were many places Windows stashed away references to the problem printer.  At this point I had decided to cut out all references to printers and print servers.  After hacking out the keys and restarting the PC, the user was able to print to the manual tray.  Problem solved and another tool to combat pesky printers had been added to my tool box.

The second occurrence happened today.  This time the user reported that they were not able to print a report to a Sharp multifunction (AR-M450U) copier in landscape mode.  Each time the print was printed out in portrait mode and this printer had started this behavior recently.  I remembered that I had just moved this printer onto another server after the server had run out of disk space (built before my time and who makes a primary partition with 4GB of space anyways? ugg this is another post all on its own).  This memory triggered to think that it was probably another registry issue.  Back into the registry I went, again hacking out all references to printers and printer servers.  Again, after a restart the issue was cleared.  The user could now print in landscape to the problem printer.

I hope these two real world examples help out some other poor sys admin when he/she are dealing with odd ball printer problems.

This is where programs called disk defragmenters come into play.  They analyze your hard drive and move the bits that are spread all over the place closer together.  Your copy of Windows comes with a basic defragmenter and there are programs you can purchase.  The Windows defragmenter will do in a pinch but it is very basic and takes some work to automate.  The commercial defragmenters do a lot more, such as "Set it and forget it", but this comes at a price.  I like programs that are free.  I use a open source program called UltraDefrag.  Diskeeper is a good commercial defragmenter, it is what I use at work.

You can run UltraDefrag using a graphical user interface or schedule it as a Windows task.  I will walk you through setting up UltraDefrag as a scheduled task.

First you must download the latest version of UltraDefrag.  As of August 2007 1.04 is the latest version.

Next we must decide what version we are going to download.  If you are running Windows XP 64 or Vista 64 you need to select the amd64 package.  If you are running 32-bit XP or Vista the i386 version is what you need.

Download and install the version you require, if the install does not work you picked the wrong version.  It would be nice if in future versions the installer queried your system to determine the correct version to install, but there are really only 2 choices for the installer.  If one does not work, try the other. 

Now we are going to write a program.  It is a very basic program but it will be the brains behind setting up free automated disk defragmentation. 

Use Windows Explorer to navigate to "C:\Program Files\UltraDefrag\". 

Click on File, New, Text Document.  A new file called "New Text Document.txt" will be listed along with the UltraDefrag program files. 

Right click on it and choose rename & type "defrag.bat".

Next right click on "defrag.bat" and choose Edit.

Now we start programming!  We need to write the command to tell windows to use UltraDefrag to run on our system, compact our fragmented files and what hard drive we want this to run on.

Lets start with the command to run UltraDefrag.  Type "defrag" (without the quotes) and press the space bar once.  This tells Windows to start the UltraDefrag program.

Now type "-c" and add a space after it.  This tells the program to defrag your hard drive. 

Finally type "c:".  This tells the program to defrag your C:\ drive.

Now click on File, Save.  You have written your first program, go ahead and pat yourself on the back, you are on your way to becoming computer geek.  

Next we are going to schedule Windows to run our program each Tuesday at 2AM.

Click on Start, Settings, Control Panel, then open Scheduled Tasks.  Now click on "Add Scheduled Task".

A wizard opens up to walk you through setting up the task, click "Next".

Click on the "Browse" button and navigate to C:\Program Files\UltraDefrag & click on your program "defrag.bat".  Now click on Open.

Next choose when you want to run the task, choose "Weekly".  Click "Next".

Now we set the time and day of our task, set this to 2AM and Tuesday.  Click "Next".

Now we have to assign the task to a user.  Enter the username and password of the computer administrator.  Most likely this will be your username and password.  Click "Next".

Click on "Finish" to end the wizard.

Now every Tuesday at 2AM UltraDefrag will run on your computer to defragment your files.

Below is a screencast showing me running through this process.  Enjoy.

Defragmentation Screencast