Fix: Can’t remove server from Backup Exec selection list


One of our Backup Exec 11d jobs failed last night with the following error in the Backup Exec job log:

Final error: 0xe000846b – The resource could not be backed up because an error occurred while connecting to the Backup Exec for Windows Servers Remote Agent. Make sure that the correct version of the Remote Agent is installed and running on the target computer. Final error category: Resource Errors

This same error was seen in the Windows Application log as Backup Exec Event 34113.

A check of the server listed in the error log showed the Backup Exec Remote Agent service had been stopped and disabled last night.  I checked with the administrator who did this, and she confirmed the server had been decomissioned and was no longer being backed up.  Oddly enough, she said she removed the server from the Backup Exec job’s selection list.

I opened up the selections list for the job in question, and lo and behold, the offending server was still selected.  I deselected the server, applied changes, re-opened the server selections – and the server was still selected.

Initial thought was something was wrong with Backup Exec, so I exited the program, restarted the BE services, went back into the application and went through the exercise of deselecting the decommissioned server and saving changes… but the server was once again selected.

The solution ended up being based on Symantec Document ID 277355.  Rather than unchecking the box next to the server’s name on the “View by Resource” tab, I deleted all of the decommissioned server’s resources on the “View Selection Details” tab.  After saving changes and exiting the application, I saw that the server was no longer showing as selected when viewing the job selections list.

Note:

My instuctions are for Backup Exec 11d. Symantec Document ID 277355 is written for BE 10.0 and 10d.  In version 10 instead of selecting the “View Selection Details” tab, change the view format from Graphical to Text.  Same thing, different terminology and GUI layout.

Fix for VMWare error: Could not open virtual machine, this virtual machine appears to be in use


This morning I received the following error when trying to power on a VMware Workstation virtual machine:

Could not open virtual machine: C:\VMs\Windows Server 2003 Standard Edition.vmx. This virtual machine appears to be in use.

To resolve the issue, I deleted all of the .lck files and directories in the guest’s directory listed above. This allowed me to start my VM. I encounter this error from time to time, yet always forget how to resolve it.

Fix: 503 Service Unavailable when accessing content on Windows Media Services 2008 server behind load balancer


I have three Windows 2008 Media servers that I’ve had issues with getting to work behind our F5 BigIP load balancer.  When we took packet traces, HTTP GET requests from the Media Player client have been responded to with 503 Service Unavailable.  

You can read all about this particular issue at the Random on Window Media blog.  The solution ended up being applying the KB960372 hotfix, which was apparently released March 13, 2009.  The hotfix KB article doesn’t exist as of today, but Random’s post suggests it will show up eventually.
[update 04-08-2009]
KB960372 is now available.
 
 
The WMS 2008 x64 hotfix can be found at

Fix: 8209 error when attempting to create an archive from a restored Groupwise post office mailbox


I recently restored a Groupwise 7.0.3HP1 post office from a daily differential backup.  After logging into a newly restored mailbox, I received a Path not Found [8209] error when attempting to create an archive from within the Groupwise client.  

The reason for the 8209 error ended up being that the daily differential backup did not capture the ngwguard.dc file located in the root of the post office directory.  Once I copied this file from the live post office to the restore location, I was able the create the archive.  I also could have copied the file from the po directory in the Groupwise software distribution directory.
 
For additional details, see Novell TID 10052390

FIX: Faulting application gwpoa.exe, version 7.0.3.1068, faulting module gwwww1a.dll


I sure hope I don’t jinx myself for considering this issue resolved…

My five Windows 2003 R2 SP2 / Groupwise 7.0.3HP1 servers have each been receiving the following errors since they were migrated from the Netware operating system back in December of 2008:

Event ID: 1000 Source: Application Error

Faulting application gwpoa.exe, version 7.0.3.1068, faulting module gwwww1a.dll, version 7.0.3.1068, fault address 0x000b2379.Event ID: 1004  Source: Application Error 

AND  

 

Event ID: 1004 Source: Application Error
Reporting queued error: faulting application gwpoa.exe, version 7.0.3.1068, faulting module gwwww1a.dll, version 7.0.3.1068, fault address 0x000b2379. 

The event 1000 would result in the POA service stopping.  I was able to temporarily minimize the impact of the POA stoppage by running the POA as a service and having it’s recovery options set to restart the service ater the failure was detected by the OS.

I noticed that the Groupwise 7 SP3 Hot Patch 2 contained an updated gwwww1a.dll, but this particular issue was not listed as a fix in the change log.  I had been hesitant to apply GW703HP2 because it caused a great headache when I applied it to my GWIA server.  I finally decided to try HP2 on my post office servers, and was plesantly suprised to find it (seemingly) has resolved my POA crash issue!  I’ll post back if I find varied results, or new issues caused by this hot patch.

Fix: The error returned when trying to retrieve these settings from the local security policy database (%windir%\security\database\secedit.sdb) was: The parameter is incorrect


Howto fix error when opening Windows Server 2003 Local Security Policy:

The Group Policy security settings that apply to this machine could not be determined. The error returned when trying to retrieve these settings from the local security policy database (%windir%\security\database\secedit.sdb) was: The parameter is incorrect.

All local security settings will be displayed, but no indication will be given as to whether or not a given security setting is defined by Group Policy.

Any local security setting modified through this User Interface may subsequently be overriden by domain-level policies.

Windows cannot read template information.

Many documents suggest that renaming the %windir%\security\database\secedit.sdb file and rebooting the server will resolve this issue by recreating the security database. Unfortunately, this procedure never resulted in the secedit.sdb database file being re-created, even after a server reboot.

I also tried importing a new secedit.sdb database, but that failed with the following error:

An extended error has occurred. Import failed.

After much Googling I came across MS KB932461 You cannot determine Group Policy security settings on a Windows Server 2003, Enterprise Edition-based computer. Even though the OS of the offending servers is Windows Server 2003 R2 Standard (not Enterprise) the fix described in the KB document fixed this issue.

The cause of the problem is explained by the KB as

“This problem occurs if specific Group Policy security settings are changed from their default settings. These security settings specify the minimum required security setting of server-side and client-side network connections for programs that use the NTLM security support provider (SSP).”

The solution was to edit the registry key
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0
Set the values of NtlmMinServerSec and NtlmMinClientSec to 0 (zero)

Wait about 15-30 minutes for the change to take effect and you should be able to view the Local Security Policy once again!

If you’re curious what these keys do, NtlmMinServerSec specifies the minimum required security setting of server-side network connections for applications using the NTLM security support provider (SSP).

NtlmMinClientSec specifies the minimum required security setting of client-side network connections for applications using the NTLM security support provider (SSP).

In my case both of these settings had previous values of 0x20080030 which enforces message integrity, confidentiality, use of NTLMv2 and 128-bit encryption.

Howto Fix: McAfee VirusScan 8.5i McAfee Common Framework returned error fffff95b


The reason you are likely receiving the McAfee Common Framework returned error fffff95b message is because the FrameworkManifest.xml file has become corrupt. To resolve this error, you need to copy the FrameworkManifest.xml from a working computer. If you do not have access to a working computer, you need to uninstall, reboot, and reinstall the McAfee VirusScan 8.5i software.

Additional symptoms of the fffff95b error:

  • DAT files will not auto-update
  • The McAfee Framework service will not stay running

How to copy the FrameworkManifest.xml file from a working computer

Perform the following from the problematic computer:

  1. Click Start > Programs > McAfee > VirusScan Console.
  2. Right-click Access Protection, then select Properties.
  3. Select Common Standard Protection.
  4. Select Prevent modification of McAfee files and settings and disable this option.
  5. Click OK.
  6. Rename the C:\Documents and Settings\All Users\Application Data\McAfee\Common Framework\FrameworkManifest.xml file to FrameworkManifest.xml.bad
  7. Copy the C:\Documents and Settings\All Users\Application Data\McAfee\Common Framework\FrameworkManifest.xml file from a working computer into the same directory on the problematic computer.
  8. Click Start > Programs > McAfee > VirusScan Console.
  9. Right-click Access Protection, then select Properties.
  10. Select Common Standard Protection.
  11. Select Prevent modification of McAfee files and settings and enable this option.
  12. Click OK.
  13. Click Start > Run and type Services.msc
  14. Right click the McAfee Framework Service and select Start
  15. Click Start > Programs > McAfee > VirusScan Console.
  16. Right click AutoUpdate and select Start.
  17. Wait a few minutes for the update to occur.
  18. Select Help > About VirusScan Enterprise and verify the DAT Created On Date has been updated.

For more information see McAfee KB54520