Affected Builds

AppAssure 5.3.x

Description

The Event’s Group on the Core console is not opening up after creating and saving a new personalized Event notification group. All functions in the Events tab locks up (ie: the “Add Group” button does not work when clicked, nor able to modify an existing notification group). All other functions are fully operational.

Solution

The cause of this issue is due to an apostrophe symbol in the notification group’s name and to fix this problem requires correcting the notification group name in the registry.

To resolve this issue:

• Stop the Core service.
• Open the Registry Editor by clicking the Start button, typing regedit into the Search box, and then pressing ENTER. If you are prompted for an administrator password or confirmation, type the password or provide confirmation.
• Locate AppRecovery folder under Computer > HKEY_LOCAL_MACHINE > SOFTWARE > AppRecovery. Right-click AppRecovery and then click Export to save it.
• Navigate to the registry path HKEY_LOCAL_MACHINE > SOFTWARE > AppRecovery > Core > Events > EventsService > CoreAlertsSettings > CoreAlertingPolicy > AdditionalNotificationGroups > 0 (0, 1, 2, etc)
• Verify the “Name” registry subkey contained in the path does contain any apostrophe symbol in the notification group’s name.
• Start the Core service.

Affected Builds

AppAssure 5 Agent All Builds

Description

The AppAssure Agent service starts and immediately stops. You right-click on the service, select Properties, and go to the Dependencies tab. You then receive a popup error: “WMI: Not Found”

Solution

1. Run the command prompt as administrator

2. Re-Register WMI by running these commands:
cd %windir%\system32\wbem
for /f %s in (‘dir /b *.dll’) do regsvr32 /s %s
wmiprvse /regserver
winmgmt /regserver

3. Perform a consistency check of the WMI repository, and rebuild it if any inconsistencies are found:
Winmgmt /salvagerepository
If that does not work, reset the WMI repository to its initial state when the OS was first installed:
Winmgmt /resetrepository

Affected Builds

Replay 4.x

Description

The agent is displaying a “License Unknown” message on the Target Core.

Solution

To resolve this issue:

On both the Replay Source and Target Core

• Stop Replay Services
• Open Registry Editor and Export AppAssure registry folder: [HKEY_LOCAL_MACHINE\SOFTWARE\AppAssure]
• Delete Agent’s registry node whose license is not replicating to the Remote core, for example:
  [HKEY_LOCAL_MACHINE\SOFTWARE\AppAssure\ReplayEPS\xxxxx]
  where xxxxx is the Agent with a problem
• Start Replay Services
• Re-protect the Agent on Source Core
• Re-establish Replication to Target Core

Affected Builds

AppAssure 5.3.x

Problem Description

Backup transfers fail intermittently with error “TevoEnableVolumeLogging failed with error -2147024858 (0×80070026 – Reached the end of the file).”

From the AppRecovery logs is the following error:

ERROR 2013-12-02T08:07:26 [153] – Replay.Core.Implementation.Transfer.TransferJob ()
Job ‘Transfer of volumes [C:\,D:\] from ‘xxxxx” failed
System.AggregateException: One or more errors occurred. —> WCFClientBase.ClientServerErrorException: Call to service method https://xxxxx:8066/apprecovery/api/agent/transfer/snapshots POST failed: The transfer failed: unexpected error —> Replay.Agent.Contracts.Transfer.TransferFailedException: The transfer failed: unexpected error —> Replay.Common.Contracts.TevoLib.TevoLibraryErrorException: TevoEnableVolumeLogging failed with error -2147024858 (0×80070026 – Reached the end of the file)

Solution

To resolve this issue:

On the Agent machine:

1. Stop Agent service

2. Run assuremc disable (on the volume in question) as follows:

a) Download AssureMC package from: http://aainfo-logs.s3.amazonaws.com/AA-1111/ReplaySupportBundle-NCLIFT-2013-03-13_09-21.zip
b) Extract the zip and browse to the extracted files
c) Click on custom files
d) Extract the appropriate assuremc.zip file (NOTE: 64-bit and 32-bit version)
e) Open an elevated Command prompt
f) Browse to where you extracted the assuremc.exe
g) Enter the following command:

assuremc disable ‘drive letter that is failing to complete snapshot transfers’

eg. assuremc disable c:
assuremc disable d:

3. Deleted aadata and aafailover files as follows:

a) Open Explorer. In order to see the ‘System Volume Information’ folder in view settings:
i. Check – Show hidden files, folders, or drives
ii. Uncheck – Hide protected operating system files
iii. Apply to Folders
b) For every volume on agent take ownership of System Volume Information folder through Properties > Security > Advanced > Owner. Be sure to check Replace owner on subcontainers and objects
c) Open an elevated Command prompt and Change directory to ‘System Volume Information’ folder
d) Run:
i. Attrib -s -h aadata
ii. Attrib -s -h aafailover

4. Run assuremc enable for each of the volumes as follows:

assuremc disable ‘drive that you disabled in step 2.g’

eg. assuremc enable c:
assuremc enable d:

5. Start Agent service

On the Core, please complete the following:

1. Open Agent > Actions > Refresh Metadata

2. Force a snapshot per KB: www.appassure.com/support/KB/forcing-a-snapshot/

Problem Description:

Semaphore timeout errors may occur when mounting a recovery point. Mounting a recovery point is required for File Recovery, Roll Backs, Virtual Standby and Export, and Mountability and Attachability Checks.

TevoMountReplay failed with error -2147024775 (0×80070079 – The semaphore timeout period has expired)

Problem Cause:

Semaphore timeout events occur when there are too many concurrent read/write requests placed on the repository at the same time.

Resolution:

Solution 1

• Pause all protection and replication (incoming and outgoing), let remaining jobs complete, and dismount all mounted recovery points.
• Make the following registry edits. Please note, if adjusting values related to AAV timeouts you must reboot the core machine for changes to take affect:
• HKLM\SOFTWARE\AppRecovery\Core\ExchangeServiceConfiguration\MountabilityCheckingProcessTimeoutMinutes set to 1440 (Decimal)
• HKLM\SYSTEM\CurrentControlSet\Services\AAVDisk\Parameters\NetworkTimeout set to 600000 (Decimal)
• HKLM\SYSTEM\CurrentControlSet\Services\AAVDisk\Parameters\AsyncNetworkTimeout to 600000 (Decimal) <= For AppAssure 5.3.4 and higher only. If DWORD does not exist, create DWORD AsyncNetworkTimeout
• HKLM\SYSTEM\CurrentControlSet\Services\AAVStor\Parameters\NetworkTimeout set to 600000 (Decimal)
• Optional:
• Go to Configuration tab, Settings, Replay Engine Configuration, and select change. Increase Timeouts to 15 minutes
• Check Page File settings. Verify they are set to automatic or between 1.5 – 3 X system RAM.
• If any changes were made to registry, stop the core service – Graceful Core Shutdown. If any changes were made to AAV timeouts or Page File settings you must reboot core machine.
• Start core service and resume jobs previously paused

Solution 2: Optional, in addition to Solution 1 or applied singularly

• Go to Configuration tab, Settings, Replay Engine Configuration, and select change.
• Set IP Address to 127.0.0.1 (local host IP), select OK

Product:

AppAssure 5.3.X

Products

AppAssure Addon For Kaseya 5.3.x
AppAssure 5.3.x

Problem Description

When attempting to upload the Web Installer Packages for Build 5.3.6.125 you receive the following error:
“ERROR:Version of AppRecovery Installation Package you trying to upload is older than existing.”

Problem Cause

This issue is due to the numbering sequence used in new builds not matching between AppAssure and the Kaseya plugin.

Resolution

Delete the existing installation packages from the Kaseya Console then upload the current ones.

Product

AppAssure 5.x

Problem Description

On build 5.3.6, when adding an agent into protection, it gets listed twice in the console. When clicking on the machines tab the error “Sequence contains more than one matching element” appears.

Resolution

1) Stop the Core service
2) Delete the C:\Program Files\AppRecovery\Core\CoreService\coreadmin folder on the Core machine
3) Perform repair of the Core

Product

AppAssure 5.x

Problem Description

Replication fails with error ” An argument was not valid in code located in or called by ‘RecoveryPointsService.WithAllRecoveryPoints’ ”

 Warning: Please make sure that no CLONED machines are present in protection – DO NOT do these steps if you have cloned machines.

Resolution

On the Source Core:

1. Stop the core service
2. Open Registry Editor and go to Registry Key HKEY_LOCAL_MACHINE\SOFTWARE\AppRecovery\Core\RepositoryService
3. Find the key (or create new) REG_DWORD ClearDuplicates and set its value to 1
4. Run check Repository job
5. When the Repository check is complete, change the key in step 3 back to it’s original value or delete it

Product

AppAssure 5.x

Problem Description

Repository shows unmounted with “Failed to open MBR file” error.

Resolution

Stop the Core service, wait for the process to end, and reboot the Core server.  Once it reboots, open the Events tab in the Core console and check for “Maintaining Repository” in active tasks.  If the repository mount fails with the same error, perform the following steps:

1. Stop the Core service
2. Open repository storage location in Windows Explorer
3. Rename “dfs.mbr” to “dfs.old.”
4. Open Notepad and save a blank file called “dfs.mbr” to the repository location.
5. Start the Core service again. 
6. The repostory should then mount properly.

Product:

AppAssure 5.3.x

Description:

After protecting an agent, when looking in the Core Console -> Agent’s Summary tab under Volumes, one or more volumes are missing.

Solution:

These steps can be used as part of troubleshooting of the issue:

1. Change “Microsoft Virtual Disk Service” (“Virtual Disk”) and “AppAssure Agent Service” service logon account: 
2. Go to Services by entering “services.msc” in the Run command and pressing Enter.
3. Change “Microsoft Virtual Disk Service” (“Virtual Disk”) logon to Local Administrator.
4. Change “AppAssure Agent Service” logon to Local Administrator.
5. Reboot agent server. 
6. Check in the AppAssure Core Console if the missing volume is now showing.

If this did not resolve the issue, configure Microsoft Virtual Disk Service and AppAssure Agent services to run under the Domain Administrator account. You will also need to make sure that UAC is disabled.

Product:

AppAssure 5.x

Problem Description:

AppAssure performs Exchange log truncation by calling a full VSS shadow copy backup. This process calls all VSS writers including the Exchange Writers. Exchange Writers coordinate with the Exchange services (operating on behalf of the requestor) to prepare the database files for backups, freeze the IO activity resulting from Exchange transactions before backing up the database, and then to unfreeze and truncate log files after the backup is complete to quiesce the application data to disk (http://msdn.microsoft.com/en-us/library/bb204080(v=exchg.140).aspx). If AppAssure is able to successfully call a full shadow copy backup and complete the backup of data to AppAssure successfully, then AppAssure will consider log truncation performed and will update the Exchange log truncation counters in the core web UI. This update will happen regardless of whether any logs were truncated or not.

Resolution:

If logs are not truncating properly then the entire process, from AppAssure calling a snapshot to logs being truncated, must be reviewed to make sure there are no errors.

If Exchange logs are not truncating please follow these steps:

1. Verify that AppAssure ran a transfer job with log truncation for the Exchange server. This event will be logged in the Core events tab. Please note the time stamp of the job. If the job failed then log truncation will not be performed. In that case the transfer failure must be resolved first. 
2. Verify there are no VSS errors in the Application Log on the Exchange server. Specifically look for errors with the Exchange VSS Writers (MSExchangeIS and MSExchangeRepl are the two possible sources of errors). If there are errors related to VSS these errors must be resolved before log truncation will work properly. To troubleshoot VSS and VSS writer issues please review this article -http://www.appassure.com/support/KB/vss-troubleshooting-guide-failed-vss-writers/. 

If there are no errors, then please review the following information regarding log truncation then it may not be necessary for Exchange to truncate logs at the time the job was run. According to Microsoft (http://technet.microsoft.com/en-us/library/dd335158(v=exchg.150).aspx_): Log truncation works the same in Exchange 2013 as it did in Exchange 2010. Truncation behavior is determined by the replay lag time and truncation lag time settings for the copy.

The following criteria must be met for a database copy’s log file to be truncated when lag settings are left at their default values of 0 (disabled):

• The log file must have been successfully backed up, or circular logging must be enabled. 
• The log file must be below the checkpoint (the minimum log file required for recovery) for the database. 
• All other lagged copies must have inspected the log file. 
• All other copies (not lagged copies) must have replayed the log file. 

The following criteria must be met for truncation to occur for a lagged database copy:

• The log file must be below the checkpoint for the database. 
• The log file must be older than ReplayLagTime + TruncationLagTime. 
• The log file must have been truncated on the active copy. 

To find the checkpoint time for a database please follow the steps in this article -http://blogs.technet.com/b/timmcmic/archive/2012/03/12/exchange-2010-log-truncation-and-checkpoint-at-log-creation-in-a-database-availability-group.aspx

Hence if there are no logs that meet the above criteria, then log truncation will not be performed. To verify that Exchange log truncation has been called and attempted to run, review the Application Log for ESE Event ID 224 and 225. Event 224 indicates that logs are being deleted and denotes the associated database. Event 225 indicates that there were no logs available for truncation.

Product

AppAssure 5.x

Problem Description:

This article outlines a procedure to test permissions on both an AppAssure Core and Agent for use in restores and backups.

Permissions may become an issue when running restores, particularly Bare Metal.  Insufficient permissions can also cause issues with backup procedures, as noted in the following KB article:

http://www.appassure.com/support/KB/deleting-aalog-information/

Resolution

Testing Permissions for Restores

The admin account for the AppAssure Core may not have full local administrator rights on the machine to be restored, leading to BootLoader, BootMgr, or boot device errors following the completion of the restore.  To test permissions, perform the following: 

1. Mount any recovery point for the Agent to be tested.
2. Open the recovery point within the mount location (default is C:\ProgramData\Apprecovery\MountPoints)
3. Navigate to c:\windows\system32
4. Open the System Volume Information folder, you may need to change folder options to allow hidden/protected files to be viewed.
5. Create a text/notepad document and open the doc.
6. Edit the text document and save it.
7. Delete the text document.

This test full read/write access. If full access rights are not granted to the logged in account for that machine, the process will error.

Testing Permissions for Backup

The admin account for the AppAssure Core may not have full local admin rights on the Agent, which can cause the aa.log change logs to not be properly truncated.  To test permissions, perform the following:

1. Connect to the Agent to be tested.
2. Navigate to the System Reserved Partition, you may need to assign the SRP a drive letter to explore it.
3. Open the System Volume Information folder, you may need to change folder options to allow hidden/protected files to be viewed.
4. Create a text/notepad document and open the doc.
5. Edit the text document and save it.
6. Delete the text document.

This test full read/write access. If full access rights are not granted to the logged in account for that machine, the process will error.

Problem Description:

The Core Web UI will freeze up and become unresponsive. Memory and CPU usage is not peaked on the Core machine. The Web UI does not become available again until after a service restart.

Problem Cause:

ERROR 2013-11-26T11:58:48 [9] – Replay.ServiceHost.Implementation.Hosting.ListenerService () Accept new requests failed System.AggregateException: One or more errors occurred. —> System.Net.HttpListenerException: An operation was attempted on a nonexistent network connection.

Resolution:

This issue is resolved in the 5.3.7.60 release of AppAssure 5

Product:

AppAssure Core 5.X

Defect ID#:

D-17097

Product:

AppAssure 5.x

Problem Description:

Can Appassure protect a Truecrypt mounted volume?

Resolution:

The AppAssure agent does not recognize Truecrypt mounted volumes and will not allow you to add them to protection. Currently there are no plans to support Truecrypt volumes, because or architecture limitations related to these types of volumes.

Product:

AppAssure 5.x

Problem Description:

CreateFile failed on file ‘C:ProgramDataAppRecoveryExportMountsADCLASERFISCHEStandby1c55cb02-ab8f-11e2-bf2e-00155d402a0f-21884_20140123-115737WindowsSystem32configsystem.LOG1′ – The device does not recognize the command 

The export status shows 100%, but the failure happens during the Making VM Bootable phase of the export.

Resolution:

Please do the following to resolve this issue:

1. Dismount all mounts and make sure that there are no active mountability, checksum, attachability checks or other tasks running. 
2. Stop AAVdisk driver (from cmd: sc stop aavdisk) 
3. Open regedit and browse to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\AAVdisk\Parameters.
4. Change NetworkTimeout to decimal value 600000, DebugFlags to 7 (hex), and Debug level to 100047 (hex) 
5. Start AAVdisk driver (from cmd: sc start aavdisk).  If the driver will not started please reboot the machine. 

Also increase the Replay Engine read and write timeout:

1. In the Core Console, navigate to the Configuration tab and select Settings. 
2. Select to change the Replay Engine Configuration. 
3. Adjust the read and write timeouts to 15 minutes 

Affected Builds:

AppAssure 5.3

Description:

Attachability checks are failing with the following error -

Sql Exception: Unable to open the physical file “C:\ProgramData\AppRecovery\MountPoints\0372f6c8-0514-401c-9486-4972e991c535\C__\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\DATA\<database-name>.mdf”. Operating system error 2: “2(The system cannot find the file specified.)”.

Solution:

This means that the database the Core is trying to run the attachability checks on is not found within that snapshot/database.

• Check the logs to find out which database it is failing on exactly. (Agent logs should show the database)
• Next, log into the SQL Server machine
• Open SQL Management Studio
• Open Databases
• Look for the database name that was referenced in the logs.
• Check to see if it is there, if it is, check to see if it holds any data or tables.
• If the database is empty, delete it – (take proper steps to back it up first if needed, then delete)
• Restart SQL Services – If you cannot restart the SQL services, skip and follow the next steps
• Go back onto the Core machine
• Click on the SQL Agent in the Core and force a new snapshot
• Once snapshot is completed, force an attachability check on the new snapshot

The issue should be resolved with any snapshots from this point and forward. The previous snapshots should be passing on all databases except for the one causing the problems(database stated in the logs), however because it failed on one database, it fails the whole job even though the other databases were successful.

Affected Builds:

AppAssure 5.3.x

Description:

After upgrading core, the repository appears stuck.
When clicking in the Core UI, it is very unresponsive and taking 15+ minutes to load a page.
Also, the Core UI may be completely unable to access.

After restarting services or ending the core process tree, you may see:
DEBUG 2014-01-03T17:01:18 [24] – Replay.Core.Implementation.Transfer.TransferSchedulerService ()
Repository initialization failed
System.InvalidOperationException: Repository initialization failed —> Replay.Core.Contracts.DedupeVolumeManager.DvmInitializationFailedException: DVM error: Failed to initialize DVM with primary cache path ‘C:\ProgramData\AppRecovery\RepositoryMetaData\PrimaryCache’, secondary cache path ‘C:\ProgramData\AppRecovery\RepositoryMetaData\SecondaryCache’, Metadata path ‘C:\ProgramData\AppRecovery\RepositoryMetaData\CacheMetadata’

Solution:

• End the AppAssure Core Process tree via task manager
• Navigate to C:\ProgramData\AppRecovery\RepositoryMetaData\
• Create a new folder called backup
• Copy all the contents of\RepositoryMetaData\ to the backup folder you just created
• Contents to copy over:
• PrimaryCache
• SecondaryCache
• CacheMetadata
• Once backed up,  Delete those 3 folders from the main \RepositoryMetaData\ folder
• Add permissions (everyone permission) and make sure the administrators account is added to the C:\ProgramData\AppRecovery folder
• Start the AppAssure services
• Go into Core -> Events and The Repository check should now be running and complete.

Problem Description:

Install or upgrade of Core or Agent fails with, but not limited to:

• Error 1. Files required for upgrade is missing. Please, repair or remove product using original installer
• Error 1612. The installation source for this product is not available.
• Modifying generic version with branded installer or vice versa is not supported. Please ensure this version comes from the same source as the currently installed version.
• AppAssure will not install or uninstall correctly.

Problem Cause:

In some cases the DLL and Registry Keys do not install or uninstall properly.

Resolution:

Solution 1

In most common cases this problem can be solved by repairing the install with the original installer. Then Upgrade to next build.

Solution 2

Msizap.exe is a command line utility that removes either all Windows Installer information for a product or all products installed on a computer. Products installed by the installer may fail to function after using Msizap.

For Agent:

1. Stop Agent service
2. Open registry, go to HKLM\SOFTWARE\AppRecovery\Agent and export AgentID folder to desktop
3. Go to Control Panel, Program and Features, and remove Agent
4. Go to C:\Program Files, if AppRecovery folder exists, delete it
5. Open registry, if HKLM\SOFTWARE\AppRecovery exists, delete it
6. Download MsiZap, in elevated CMD, change directory to MSIZAP location and run:
   • 32 bit systems: msizap T! {7A43B7BA-AAFC-4F9D-A205-1E59994695EB}
   • 64 bit systems: msizap T! {82556F7B-51A3-45D8-8B9D-7C85B2B7B8C4}
7. Reboot server
8. Install Agent using .EXE installer or use 7-Zip (or comparable app) to extract files from .EXE installer and run .MSI file to install
9. Stop Agent service, open registry, go to HKLM\SOFTWARE\AppRecovery\Agent and delete AgentID folder
10. Go to desktop and inject exported AgentID from step 2, start Agent service

For Core:

1. Stop Core Service, make sure MongoDB is stopped as well
2. Open registry, go to HKLM\SOFTWARE and export AppRecovery folder to desktop
3. Go to Control Panel, Program and Features, and remove Core
4. Go to C:\Program Files, if AppRecovery folder exists, delete it
5. Open registry, if HKLM\SOFTWARE\AppRecovery exists, delete it
6. Download MsiZap, in elevated CMD, change directory to MSIZAP location and run msizap T! {F1AD8970-6853-4DA0-8DA1-DACAC27E51B8}
7. Reboot server
8. Install Core using .EXE installer or use 7-Zip (or comparable app) to extract files from .EXE installer and run .MSI file to install
9. Stop Core service, open registry, go to HKLM\SOFTWARE and delete AppRecovery folder
10. Go to desktop and inject AppRecovery folder from step 2, start Core service

Product:

AppAssure 5.X.X

Affected Builds

Replay 4.x

Description

There are missing recovery points inside the core console, however they show in the repository.

Resolution

To resolve this issue, here are the steps that you can perform to ensure that the data from the tevorepository is accurately displayed in the Replay core admin console. These are actually troubleshooting steps to force the core server to rebuild its “enginedb” folder :

1. Close the Replay Admin Console
2. Stop the “replay core” service
3. Find the “enginedb” folder – it is located in the user folder under the name of the service account used to run the replay core service. for example: C:\Users\\AppData\Local\Temp\EngineDB (your service account may not necessarily be named “svc_appassure”)
4. Rename the enginedb folder to “enginedb.OLD”
5. Restart the “replay core” service
6. Open the Replay Admin Console

The system will automatically build a new enginedb folder and recreate its contents, as this happens the protected servers will start to repopulate the Replay core admin console. This may take anywhere from 5 to 30 minutes, depending on the resources of the core server and the number of protected servers configured.

Next, you will need to force a rollup on each of the agents concerned with by going to Properties > Retention Policy tab > Run Now.

Now if you are able to see some of the recovery points in the Replay admin console but still not all the data is being displayed, then the next step is to employ this registry edit:

Please add this registry entry in: HKLM\SOFTWARE\Appassure\ReplayEPS\AGENTNAME

1. Create a new dword value for cleanup_invalid_files
2. Set the decimal value to 1
3. Restart the core service
4. Force a rollup.

Note: Any and all recovery points that are invalid or rely on invalid recovery points will be pruned after this entry is added. The only other option though is to archive the current data and start fresh with a new base image.

There are a lot of things that can cause invalid recovery points, such as drive issues or heavy fragmentation, something odd happening during the roll-up process like a power outage.

Affected Builds

Appasure 5.x

Description

This issue occurs if the agent machine that is protected is experiencing a Performance issues whereby the network share browse-ability is witnessed to be quite slow or unresponsive, and then after a brief window if some x number of minutes, normal performance is resumed.

Resolution

Here are the steps to begin troubleshooting this issue:

1. Extend the Appasure agent timeout setting in the registry (MetadataAccessTimeout) at the path HKEY_LOCAL_MACHINE\SOFTWARE\AppRecovery\Agent\AgentTransferSettings > MetadataAccessTimeout (Change from default 01:20 to 10:00)

2. If you notice any evidence of large amounts of VDS warnings in the Windows system event logs, change to using Win API.

To change the agent to use WinAPI instead of VDS, set the following at the registry path HKEY_LOCAL_MACHINE\SOFTWARE\AppRecovery\Agent\AgentSettings > DisableVdsServiceMetadata (Change from default 0 to 1)

Here are a couple reference links about this setting change: http://msdn.microsoft.com/en-us/library/windows/desktop/hh830613(v=vs.85).aspx

http://msdn.microsoft.com/en-us/library/windows/desktop/aa381442(v=vs.85).aspx

3. If the WinHTTP Web Proxy Auto-Discovery Service is not set to manual startup, change it so that is set to “Manual”.

This step has been shown to be effective when the WinHTTP Web Proxy Auto-Discovery Service service is entered in a stopped state during the specific window of time.

4. Check for any errors/warnings/alerts in the System and Application event logs, and fixed these issues next.

For example, if you notice there are the following two events:

Event ID 5722: “The session setup from the computer COMP32 failed to authenticate. The name(s) of the account(s) referenced in the security database is COMP32$. The following error occurred: Access is denied.”)
To address this, please apply a solution from Microsoft per this KB http://support.microsoft.com/kb/810977

Event ID 1058 — “Group Policy Preprocessing (Networking)” )

To address this, please apply a solution from http://technet.microsoft.com/en-us/library/cc727259(WS.10).aspx

5. Next, re-protect the agent by entering its hostname (if it had been originally protected via IP) or if it had been protected by hostname originally, then please re-protect the by entering its IP instead.

6. If this issue continues to occur, contact Support by creating a case on the Support Portal for further investigations.