Backup Exec service is not runing in symantec backup server

Check for a process called "LUGetUpdatesExe.exe" and kill it - afterwards services should start up again. To avoid this happening again disable Live Update then

How to use BEMIG to manually upgrade the Backup Exec database from a previous version

Product(s)

• Backup Exec

Subject

• Troubleshooting
• Installing

• Italiano
• 한국어 (Korean)
• 中文 (简体) (Simp. Chinese)
• 中文 (繁體) (Trad. Chinese)
• Show less

Problem

Need to manually upgrade Backup Exec from a previous version.

Solution

The recommended upgrade method is to allow the Backup Exec (BE) installer upgrade BE and its database during the installation. If that fails to occur or a saved database from a previous BE version needs to be added to a newer BE version, the BEMIG tool can be used. This tool follows the same upgrade version rules that the BE installer has. This is noted in the chart below.
Note: If the .mdf and .ldf files are from an older version of Backup Exec installed on a different server then please do not follow the procedure below if any of the following are true:

• Backup Exec is clustered.
• The Backup Exec Shared Storage Option (SSO) is installed.
• The Backup Exec Server Free Option is installed.
• The computer where Backup Exec is installed and the computer where it will be installed are running two different versions of the Windows Operating System.
• If planning to move Backup Exec to a different drive/directory on the server.
• If upgrading from one version/revision (build) of Backup Exec to another

Steps:

1. Confirm BE is working in its current database first.

2. Stop the all Backup Exec services (including the  SQL(BKUPEXEC) service)
3. Open the \Program Files\Symantec\Backup Exec Directory.  Copy the Data folder and paste it in the same location. Rename the "Copy of Data" to "Data-'TodaysDate' or "Data-Version#-New"

4. Copy the saved Database from the previous BE version into the Backup Exec\Data folder.
   This will be bedb_dat.mdf and bedb_log.ldf files.

5. If the Catalogs have been saved also, rename the Catalogs to Catalogs.old, then copy/move the saved catalogs under Backup Exec.

6. Start the SQL service.

7. Set the registry keys for BEMIG.

Warning: Incorrect use of the Windows registry editor may prevent the operating system from functioning properly. Great care should be taken when making changes to a Windows registry. Registry modifications should only be carried-out by persons experienced in the use of the registry editor application. It is recommended that a complete backup of the registry and workstation be made prior to making any registry changes.

7a. Launch the Registry Editor (Start, Run, Regedt32).
     Navigate to HKLM | Software | Symantec | Backup Exec for Windows | Backup Exec | "VersionNumber" | Install             
   


7b. Modify the value of "Upgrade" to 1.
      (Create as a Dword if it is not present)

7c. Modify the value of  "Upgrade Version" to the version of the DB being imported. See chart.
      (Create as a String value if not present)
Please refer the following Table while setting the value for Upgrade version Key.

PRODUCT VERSION	UPGRADE VERSION	10	10D	11	11D	12.0	12.5	2010	2010 R2
9.1 revison 4691	9.1.4691.0	X	X	X
10.0 revison 5484	10.0.5484.0	X	X	X
10.0 revison 5520	10.0.5520.0		X	X
10.1 (10d) revison 5629	10.1.5629.0			X	X	X
11 revison 6235	11.0.6235.0				X	X
11 (11d) revison 7170	11.0.7170.0					X	X	X	X
12.0 revison 1364	12.0.1364.0						X	X	X
12.5 revison 2213	12.5.2213.0							X	X
2010 revison 2896	13.0.2896.0								X
2010 R2 revison 4164	13.0.4164.0

  8.Open a CMD command prompt to \Program Files\Symantec\Backup Exec
  Run BEMIG
  Wait for it to fully complete and return to a new prompt.

9. Start BE services and open the BE console.

Note, if the services fail to start, you may need to do additional steps of:

1. Stop the SQL(BKUPEXEC) service
2. Copy the BEDB database files from the Data folder to the desktop
3. Start the SQL(BKUPEXEC) service
4. Run BEutility Copy Database to import the desktop BEDB files. This will correct any Environmental changes effecting the database.
              Copy Database Document -  http://support.veritas.com/docs/286093

How to migrate (move) Backup Exec from one system to another with the same version of BE, Windows and same or different computer names.

Product(s)

• Backup Exec -> 12.0 -> 12.5
• Backup Exec -> 12.0
• Backup Exec -> 11d (11.0)
• Show all
• Backup Exec -> 10.0 -> 10d (10.1)
• Backup Exec -> 2010 -> 2010 .R2
• Backup Exec -> 2010
• Show less

Problem

How to migrate (move) Backup Exec from one system to another with the same version of BE, Windows and same or different computer names.

Environment

Instructions for moving Backup Exec (tm) 10d or above to another computer system which has the same version installed. The target systems can have the same computer name or a different computer name.

 

 

The information in this TechNote applies to the following scenarios: 
 

• Moving an installation of Backup Exec from one 32-bit system to another 32-bit system.
• Moving an installation of Backup Exec from one 64-bit system to another 64-bit system.
• Moving an installation of Backup Exec from a 32-bit system to a 64-bit system.
• Moving Backup Exec to another system where the Backup Exec Database (BEDB) is installed on a SQL 2000, 2005, or 2008 instance.
• Moving Backup Exec to another system where the system being moved is a Central Administration Server (CAS).
• Moving DLO from one Backup Exec system to another Backup Exec system. 

Do not follow this procedure if any of the following are true: 
 

• Backup Exec is clustered.
• The Backup Exec Shared Storage Option (SSO) is installed.
• The Backup Exec Server Free Option is installed.
• The computer where Backup Exec is installed and the computer where it will be installed are running two different versions of the Windows Operating System.
• If planning to move Backup Exec to a different drive/directory on the server.
• If upgrading from one version/revision (build) of Backup Exec to another.

NOTE:  If any of the above mentioned conditions are true, this procedure cannot be performed and Backup Exec will need to be re-installed and re-configured.

NOTE: Prior to moving Backup Exec versions from one system to another the following upgrade paths need to be followed:
 

• When moving from a 32-bit system to a 64-bit system it is recommended that any Backup Exec version upgrades should be performed on the 32-bit system first prior to following the instructions contained in this TechNote.

Solution

Instructions for moving an installation of Backup Exec

The Backup Exec move process consists of five sections:

I.  Prepare the current Backup Exec installation on the source computer system.

II.  Move Backup Exec data to a temporary storage location.

III. Install Backup Exec on the new Backup Exec target media server.

IV. Move the Backup Exec data from the temporary storage location to the new target Backup Exec media server.

V.  Verify that the new Backup Exec installation matches the original Backup Exec installation.

Important Note: Do not remove Backup Exec from the original computer until the migration of data and media to the new Backup Exec media server is complete. It must be verified that the new Backup Exec installation matches the original installation.

I.   Prepare the current Backup Exec installation:

In order to move Backup Exec from one computer to another, the following preparation must be performed on the original Backup Exec media server:

1.  Backup Exec Version and Revision Number - Write down the Backup Exec version and revision number listed on the Backup Exec Help | About Symantec Backup Exec for Windows Servers menu.
 

2.  Update Backup Exec Software - Install all the Backup Exec software updates (hotfixes and service packs) available for the Backup Exec version and revision currently installed. Software updates can be obtained from either the Backup Exec Technical Support site ( http://www.symantec.com/enterprise/support/downloads.jsp?pid=15047) or Symantec LiveUpdate.

3.  Installed Backup Exec Options, License Keys, and Installation Path - Write down a list of the installed Backup Exec options, license keys and the installation path from the existing Backup Exec installation.

To obtain this information, follow these steps:

Open Backup Exec. Select Tools | Install Options and License Keys on this Media Server from the Backup Exec menu. After the license keys are obtained, precede through the install screens to obtain the install path. Once this information is obtained, the install can be canceled.
 

 

Figure 1 - Record Backup Exec License Keys
 
 

Note:  Backup Exec keeps a record of the Backup Exec license keys currently installed in a file named BESERNUM.XML. This file is located under Documents and Settings\All Users\Application Data\Symantec\Backup Exec. The license keys listed in this file can be imported (see Figure 1) during the installation on the new Backup Exec media server instead of manually entering the license keys. To use this file during the installation of the new Backup Exec media server, save the file to location on the new Backup Exec media server so it can be retrieved when needed.

4.  Identify backup-to-disk folder locations - Write down the path of all backup-to-disk folders. To obtain this information, follow these steps:

a. Open Backup Exec.
b. Select the Devices view.
c. Highlight Backup-to-Disk Folders, right click and select properties. 

Note location of B2D folder (see figure 2)
Figure 2 - Backup to Disk folder location

II. Move Backup Exec data to a temporary location

Perform the following steps on the original Backup Exec media server:

Note: If the server in question that is being moved is a CAS server, then prior to shutting down the services ensure that all of the Backup Exec services for each Managed Media Server that communicates with the CAS are shut down as well.

1.  Stop all Backup Exec and DLO (if installed) services - Using the Windows Services applet; stop the following Backup Exec services: (Figure 3 and Figure 4)
 

• Backup Exec Agent Browser
• Backup Exec Device and Media Service
• Backup Exec DLO Administration Service (only if DLO is installed)
• Backup Exec DLO Maintenance Service (only if DLO is installed)
• Backup Exec Job Engine
• Backup Exec Remote Agent for Windows Servers
• Backup Exec Server

2. Stop the Backup Exec SQL Server service (a separate DLO Instance will also exist with 10d)
 

• SQL Server (BKUPEXEC) - This is a SQL Express instance. Stop this instance if it is the instance that the Backup Exec (BEDB) and DLO (BE_DLO) databases are using.
• SQL Server (MSSQLSERVER) - This is SQL Server instance (local or remote). This is a default SQL instance. This can be a SQL 2000, SQL 2005, or SQL 2008 instance.  Stop this instance if it is the instance that the Backup Exec (BEDB) and DLO (BE_DLO) databases are using.
• SQL Server (SQL2005ONE) - This is a SQL Server named instance (local or remote). This can be a SQL 2000, SQL 2005, or SQL 2008 instance.  Stop this instance if it is the instance that the Backup Exec (BEDB) and DLO (BE_DLO) databases are using.

 Figure 3 - Backup Exec and DLO Services

 

Figure 4 - SQL Service where Backup Exec and DLO databases are installed

 

 

6.  Copy Files - Using Windows Explorer, copy the following Backup Exec directories (files) to a temporary location keeping the directories separate:
 

• C:\Program Files\Symantec\Backup Exec\Data

 IMPORTANT NOTE - Do NOT copy the msgq*.*.dat files over to the temporary location (see Figure 5)

 

Figure 5 - BE\CASO message queue files

 

• C:\Program Files\Symantec\Backup Exec\Catalogs

NOTE: If this is a CAS server, make sure to copy over the Catalog folders for the Managed Media Servers as well. These should all be listed under the Catalogs folder.

• C:\Program Files\Symantec\Backup Exec\IDR (if present)
• C:\Program Files\Symantec\Backup Exec\Reports\Saved
• Backup-to-Disk folders as mentioned in section I - step #4 above (if created)

Note: The only files that must be copied over are the B2D*.*.bak files. These are the actual media (see Figure 6)

 

Figure 6 - Backup to Disk Media

 

Important Note:  At this point, if the source computer name is the same as the target computer name then turn off the source (32bit computer) and turn on the target (64bit computer). The domain/workgroup information should also match.

 

III. Installing Backup Exec on the new Backup Exec media server

Perform the following steps on the new Backup Exec media server:

1.  Install Backup Exec - Install the same version and revision of Backup Exec that is installed on the original Backup Exec media server. If moving to a 64-bit system, use the 64bit Backup Exec installation CD instead of the 32bit installation CD.

NOTE:  When prompted for Backup Exec license keys, enter the Backup Exec license keys from the original Backup Exec media server. If using the Backup Exec license keys file BESERNUM.XML to enter the license keys, select the Import button (see Figure 7) and point to the location of the saved license key file.
 

 

Figure 7 - Import License Keys from Source System
 

NOTE:  When prompted for the installation path, use the same path as the original Backup Exec media server. For example, if the path C:\Program Files\Symantec\Backup Exec\ was used in previous installation, then use the same path.

NOTE: The SQL install path can be changed. If the Backup Exec (BEDB) and DLO (BE_DLO) databases were installed to a SQL Express instance, the databases can be moved to another non SQL Express instance. The database files can be moved to any SQL 2000, 2005 or 2008 instance as long as the database files are being moved to the same or newer version of SQL (i.e. SQL 2008 files cannot be moved to a SQL 2005 instance and SQL Server files cannot be moved to a SQL Express instance).

2.  Reboot - Restart the computer (do not open Backup Exec after rebooting).
 

3.  Install Updates - Install all the Backup Exec software updates (hotfixes and service packs) available for the Backup Exec version and revision currently installed.  Software updates can be obtained from either the Backup Exec Technical Support site (http://www.symantec.com/enterprise/support/downloads.jsp?pid=15047) or Symantec LiveUpdate.

4. Reboot - Restart the computer (do not open Backup Exec after rebooting).

 

IV. Move Backup Exec data from the temporary location to the new Backup Exec media server

Perform the following steps on the new Backup Exec media server:

1. Stop all Backup Exec services - Stop all Backup Exec services (a list of Backup Exec services can be found earlier in this TechNote Section II - Step #1).

2. Stop the SQL Service (a list of Backup Exec services can be found earlier in this TechNote, Section II - Step #2).

3. Copy Files - Copy the Backup Exec files from the temporary directories, overwriting the data, catalogs, and Intelligent Disaster Recovery (IDR) folders on the new system.

4. On the new or target system, create a folder where the new Backup to Disk folders will reside.  Copy the saved off .bkf file(s) from the temporary location into this folder.

NOTE: Perform Step 5 only if you are moving the installation to a system with a DIFFERENT computer name. If the installation is being moved to a system with the SAME computer name, skip this step and go to the next step, step 6. Step 5 is required because the new database will have the name of the old database and will have to be changed before the Backup Exec services can start.

5. Rename the DataPartition name for the Backup Exec Database that was copied.

Refer to the steps mentioned below:

a. Start the SQL Server (BKUPEXEC) service or SQL Service where Backup Exec is installed.
b. Open a command prompt and type Sqlcmd -E -S servername\BKUPEXEC
c. If successfully connected to the server, the following prompt appears: 1>  This indicates a connection to the Backup Exec instance using Sqlcmd (see Figure 8).
 

 

Figure 8 - Make a Connection to the SQL Instance
 
 

·Run the following query from either Sqlcmd or from the SQL Management tools:

 

Use bedb

<Press enter>

Type go

<Press enter>

SELECT partitionname FROM datapartition

<Press enter>

Type go

<Press enter>
 

 

After pressing ENTER the original server name is listed.  Running this query will yield the current database partition name that the database has (which is the old one)

Change this name from the original server name to the new Backup Exec  server name by typing the command below. This will update the database with the partition name of the new server.

 

UPDATE DataPartition SET PartitionName='<this server name>' WHERE PartitionID =0

<Press enter>

Type go

<Press enter>

 

· Run the select statement again and verify that the name was changed to the new server name:

 

SELECT PartitionName FROM DataPartition

<Press enter>

Type go

<Press enter>

 

Figure 9 shows what the process looks like...

 

Figure 9 - Query Display for Changing Computer Name in the Database

 

 

· Type quit to exit Sqlcmd

6. Start all Backup Exec services - Start all the Backup Exec services which were stopped in Step 1.

 

V.  Verify that the new Backup Exec installation matches the original Backup Exec installation

Perform the following steps on the new Backup Exec media server:

 

1. Start Backup Exec - Start the Backup Exec application and verify that the Backup Exec data was correctly moved.

· Verify that the Jobs, Selection Lists, Policies, Alerts, and Job History are correct

2. In Backup Exec go to Devices Tab; the old server name with off-line devices should be listed under the source server name (see Figure 10).
 

 

Figure 10 - Off line devices from the Old System
 

Delete the old server (source) entry and its devices by right clicking on the device and selecting Delete.

3. Clean out media not being used - If there is media from devices that are no longer in use, clean this up from the new Backup Media Server as well (see Figure 11). From the Media Tab, move all of the offline media that will no longer be used over to the retired media set and delete it.
 

 

Figure 11 - Media from Source that is no Longer being used
 
 

 

4. Create a new Backup to Disk folder under the current (target) server's Backup to Disk devices and recreate catalogs.

a. Create a new folder for the B2D media and configuration files.
b. Copy the B2D media from the temporary location into the folder just created
c. Create the B2D folder and point to the path of the new folder (see Figure 12)
d. Run an inventory job on the B2D media
e. Run a Catalog job on the B2D media

NOTE: If the Target server is a CAS, run the inventory and Catalog job on the Media after the CASO Configuration changes (listed in the CASO Configuration section below) have been performed.
 

NOTE: If a catalog job is run on Media on the CAS or MMS(s) the media is now considered imported and may be subject to be overwritten. Check the media overwrite protection that is currently configured to ensure that media that is needed will not be overwritten.
 

Figure 12 - Backup to Disk create on Target System

 
 

 

5. Review the Backup Selections Lists. If the old server was being backed up locally, it will need to be changed to backup remotely under remote selections. Viewing the selections in text mode may be necessary to remove the old server local selection. Additionally, the new server will need to be added to the selection list if it needs to be backed up (see figure 13).

 

Figure 13 - Update Source System Local Selections on Target System
 
 

 

6.  On each of the remote machines that are backed up (if any), vxmon.exe needs to be run to point publishing to the new box. Open "C:\Program files\Symantec\Backup exec for windows\RAWS\Vxmon.exe", click on the Publishing tab, add the new server.  If the old server is listed, remove it.  

Configuration Steps for Target Server if it is a Central Administration Server (CAS)...

If the new Media server is a Central Administration Server (CAS) and it has attached Managed Media Servers than the following additional steps should be performed...

The MMS(s) should be in a no-communication state since its services were shut down earlier (see Figure 14)
 

Figure 14 - CASO Managed Media Server in Unavailable State
 
 

1. Delete the current msgq files on the Managed Media Server (see Figure 15). These message queue files are associated with the old CAS and will get regenerated on the Managed Media Server during service startup. Navigate to the data folder where these files are stored. The default location is C:\Program Files\Symantec\Backup Exec\Data
 

Figure 15 - CASO Managed Media Server files
 
 

2. Change the Managed Media Setting to communicate with the new CAS

If the new Central Administration Server (CAS) was just moved from one computer system to another but the name has remained the same, then just start up the services on the Managed Media Server and it should show as On-Line and Manageable from the Central Administration Server.

However, if the new Central Administration Server was moved from a system that has a different name, then some registry keys on the Managed Media Server will have to be changed in order for the Managed Media Server to communicate with the new Central Administration Server.

The keys that need to be changed are as follows...
 

Warning: Incorrect use of the Windows registry editor may prevent the operating system from functioning properly. Great care should be taken when making changes to a Windows registry. Registry modifications should only be carried-out by persons experienced in the use of the registry editor application. It is recommended that a complete backup of the registry and workstation be made prior to making any registry changes.

 

HKLM\Software\Symantec\Backup Exec for Windows\ADAMM\

 

Change the Database Server Name key to the new server name

 

If the instance name has changed as well, then the Database Instance Name key will also have to be changed to the new instance name. If the source system used a named SQL instance but the target now uses a default instance, then the instance name should be removed from the instance name key.

 

Note: If the Managed Media Server is not sharing the database on the Central Administration Server than changing this ADAMM key should not be necessary. It should point to the local server, which is the Managed Media Server.

 

HKLM\Software\Symantec\Backup Exec for Windows\Backup Exec\Server\

 

Change the DjmPrimaryServer key to reflect the name of the new Central Administration Server. Changing this key ensures that communication through the Message Queue can now take place between the new CAS and the MMS.

3. Start up all of the Backup Services on the Managed Media Server(s). Once these services are started the MMS(s) should now display as available from the CAS.

4. Catalogs for the CASO environment:

• For the Central Administration Server and for the B2D folder and media that is on the CAS, run an Inventory and Catalog job to retain the catalogs for the CAS media.
• If there are MMS(s) that have their catalogs Centralized and the catalogs were copied, as noted in Step #6 of Section II above, then they should show up under Restore selections on the CAS. If the catalogs do not show up, then, from the CAS, run an Inventory Job and Catalog job on the device\media for that particular MMS.
• If there are MMS(s) that have their catalogs Distributed and the catalogs were copied, as noted in Step #6 of Section II above, then they should show up under Restore selections on the CAS. If the catalogs do not show up, then, from the MMS, run an Inventory Job and Catalog job on the device\media for that particular MMS.

NOTE: If a catalog job is run on Media on the CAS or MMS(s) the media is now considered imported and may be subject to be overwritten. Check the media overwrite protection that is currently configured to ensure that media that is needed will not be overwritten.

Configuration Steps for Target Server if it is a DLO (Desktop and Laptop Option) Server...

The DLO database has no configuration requirements on the database name so no changes will have to be made to the database in order to use DLO on the target server. However, there are some configuration changes that need to be made to the DLO Server and Desk Top agent in order to use DLO with the new target server.
 

Figure 16 - Create new DLO Storage Location
 

1. If the old Storage Location was on the source server and the source server will be put of commission, it may be necessary to create a new storage location (see figure 16) on the target server or on another server that can hold the user DLO Data.

NOTE: If the source server is not being put out of commission, the old Storage location still can used if the user wishes to do so.
 

Figure 17 - Move user data from old Storage Location to new Storage Location
 

2. If it has been determined that the DLO user data needs to be transferred to a new Storage Location, then the user can transfer the data by opening the DLO Console, selecting the user, and then select to Move the Network User Data Folder (see Figure 17).
 

Figure 18 - Change Automated User Assignments to new Storage Location
 

3. If the Storage Location has been changed, it will be necessary to change the Automated User Assignments. Select the name from the Automated User Assignments (See Figure 18), and change the Storage Location to the new Storage Location.
 

Figure 19 - SQL Server Configuration for Named Pipes
 

4. Once the DLO database has been moved to another SQL instance it is necessary that you check the SQL Server protocol Named Pipes and ensure that this protocol is enabled (See Figure 19). DLO uses this protocol for its Desk Top Agent. If this protocol is not enabled, the Desk Top Agent will not be able to communicate to the DLO Server.

NOTE: Once the Named Pipes protocol is enabled, it will be necessary to restart the SQL Service for the change to take place.

5. Once the SQL Protocols are configured, the DLO agents on the Desk Tops and Laptops should find the new Server and connect to it. Check the options on the Agents to ensure that the Storage Locations (if moved) are correct (See Figure 20). If they are not correct, it may be necessary to uninstall and then reinstall the agent so that they properly pick up the correct configurations from the server.

NOTE: if the Agents are uninstalled, be sure to select NO to the option to uninstall the user data from the Desk Top\Laptop. If this is not done, the user will only be able to retrieve data from the server.
 

Figure 20 - DLO Desktop Agent Properly Communicating with DLO Server
 

/apps/media/inquira/resources /resources

Fix: Infinite “Configuring Updates 3 of 3. 0% complete.”

Posted in Fixes | Comments (20)

This one was apparently fixed by Microsoft a while ago but in case you run into something similar it’s helpful. It will work on any problem where an update has hijacked the screen with an “Update in progress” type of message and won’t let you finish booting windows. This fix will clear that bad update.

Problem: You run Windows Update and select your updates. Once they download everything they prompt you to restart your system. You do so, the computer turns off then on again and windows starts to boot until you see a screen saying: “Configuring updates 3 of 3. 0% complete.” No matter how long you wait and no matter how many times you restart the screen does not go away.

Fix: You need to delete the “pending.xml” file. The file has a list of updates and forces windows to install those updates at startup. By deleting the file you delete the list so Windows ignores the updates.

THE FIRST METHOD:

Microsoft has a fix for this problem up on their website (here) and we’ll take a look at that method first.

The Microsoft “fix” basically tells you to use restore points to send your computer back in time. How far back? Well just far enough so that your computer is in a state before the broken updates were downloaded. The closer this date is to the present the better. If you restore too far back you end up with programs that don’t work and have a confused computer.

So how do you restore without being able to boot into windows? Again, there are two methods:

1. Take your Vista disc and insert it into the computer. Ensure that your booting with the CD and when the disc loads press “R” as soon as you see the option. Invoking this command will launch the repair section of the Windows CD which contains a System Restore program. Just select the closest time to the present and restore to that.
2. Boot into safe mode.
3. Click Start, a menu will pop up.
4. Click Run from the menu. A window will pop up.
5. Type in: “rstrui.exe” This will launch the system restore utility.
6. Select the closest restore point to the present.

After the restore is done you will find that you can boot into windows once again! There is one more step that you need to do. Microsoft recommends installing an update to windows update, crazy eh? You can find that update here make sure that you download and install this right away.

THE SECOND METHOD:

Now in case for some reason the restore point solution doesn’t work for you there is a second method. I got this fix from a fellow tech and unlike the recovery points method this one just modifies the “pending.xml” file. What you basically need to do is delete “pending.xml”. It is not a file that can be deleted easily when you don’t have access to Windows. But of course our favorite tool comes in handy again-

Download and install a copy of The Ultimate Boot Disc for Windows it’s a useful tool to have for these and other kinds of windows problems. Boot from the disc and in the menu that pops up choose Ultimate Boot Disc for Windows (or something of the like.) The next step will take a few moments so get some coffee, or alcohol depending on your mood. There! You will see that we have loaded a modified version of Windows! One filled to the brim with cool tech tools!

Select the “Computer” or “My Computer” icon. This will launch a folder with a list of all of your drives. Select the drive that contains your windows installation.

1. Click on the Windows folder.
2. Click on the Winsxs folder.
3. Find the file pending.xml.
4. Right click>Properties.
5. Go to the Permissions tab and give yourself full control over the file.
6. Click Apply.
7. Delete pending.xml.

Once we delete the “pending.xml” file windows no longer looks to it for instructions to install updates and we are free to boot into windows normally.

The next time you download updates that need to be installed Windows will recreate the pending.xml file with new correct updates and you’ll be good to go. Once you get into Windows don’t forget to download and install the windows update fix, it can be found here.

How to explain this problem to the client:This is caused by a bad update Mr. Customer, you know how Microsoft is (insert bonding laugh here.) I’ve usually seen it affect HP/Compaq AMD based unit mostly and you will now be safe from this error in the future. Hooray!