Issue: Automatic Updates (AU) service is disabled by group policy, attempting to start the service results in the following error on a Windows XP SP2 machine: 

regsvr32 wuaueng.dll

Remko Weijnen has released a kernel patch that allows x86 versions of Windows Vista to address more that 4GB of RAM.  I’m going to try it on my home Vista PC tonight.  The patch has been tested with SP1 and SP2.

Remko explains how his patch works, and states that the reason why Vista x86 can’t address more than 4GB of RAM isn’t a hardware limitation… it’s a Microsoft licensing limitation.

The following entries were found in the C:\Documents and Settings\All Users\Application Data\McAfee\Common Framework\Db\Agent_servername.log file on my Windows 2003 server:

20090709133245 I #1972 InetMgr Adding site ePO_mysite to failover list.
20090709133245 I #1972 InetMgr After calling UploadFileResponse()
20090709133245 i #1972 Agent Package uploaded to ePO Server successfully
20090709133245 i #1972 Agent Agent communication session closed
20090709133245 i #1972 Agent Agent received POLICY package from ePO server
20090709133245 I #1972 Agent Started processing a package..
20090709133245 I #1972 Agent Processing PropsResponse package
20090709133245 I #1972 Agent Looking for new sitelist from server
20090709133245 i #1972 Agent New Site List file was received
20090709133245 I #1972 Agent Looking for new event filter from server
20090709133245 I #1972 Agent Looking for new policy from server
20090709133245 I #1972 IPLock writeLock – providing write lock
20090709133245 E #1972 Xml Error trace:
20090709133245 E #1972 MgRcSvX [Merge server.xml]->
20090709133245 E #1972 Xml [useExistingFile,C:\Documents and Settings\All Users\Application Data\McAfee\Common Framework\Server.xml]->
20090709133245 E #1972 Xml [ReadBufferFromFileNoExp,C:\Documents and Settings\All Users\Application Data\McAfee\Common Framework\Server.xml]->
20090709133245 E #1972 Xml Couldn’t convert to Unicode
20090709133245 I #1972 IPLock writeUnLock – unlocking the write lock successful
20090709133245 e #1972 Agent New server policy was NOT successfully merged
20090709133245 i #1972 Agent Enforcing newly downloaded policies
20090709133245 I #1972 Agent Agent Enforce Policy Interface called
20090709133245 i #1988 Agent Agent Started Enforcing policies
20090709133245 I #1988 Agent Thread signal occurred
20090709133245 I #1988 Manage Enforcing policies
20090709133245 i #1972 Agent Agent will connect to the ePO Server in 60 minutes and 0 seconds.
20090709133245 I #1988 IPLock writeLock – providing write lock
20090709133245 i #1988 Manage Compiling policies
20090709133245 I #1988 Manage CPolicyFile::InitializePolicyFiles() – Server policy invalid
20090709133245 I #1988 Manage Compiling Policies FAILED, result=-3
20090709133245 I #1988 IPLock writeUnLock – unlocking the write lock successful
20090709133245 I #1988 Agent Agent policy enforcement failed, result=-3
20090709133245 i #1988 Agent Agent finished Enforcing policies
20090709133245 i #1988 Agent Next policy enforcement in 5 minutes
20090709133300 i #1988 Agent Agent Started Enforcing policies
20090709133300 I #1988 Agent Thread signal occurred
20090709133300 I #1988 Manage Enforcing policies
20090709133300 I #1988 IPLock writeLock – providing write lock
20090709133300 i #1988 Manage Compiling policies
20090709133300 I #1988 Manage CPolicyFile::InitializePolicyFiles() – Server policy invalid
20090709133300 I #1988 Manage Compiling Policies FAILED, result=-3

The Solution

1. Stop the McAfee Framework Service

2. In the C:\Documents and Settings\All Users\Application Data\McAfee\Common Framework directory delete the following two files:

server.xml
compiled.xml

3. Restart the McAfee Framework Service

4. Perform Agent wakeup per KB52707 by executing

C:\Program Files\Common Framework\cmdagent.exe /C

This command checks for new policies/tasks

See McAfee KB60422 for additional details

To delegate the ability to enable and disable user accounts in Active Directory:

1. Launch Active Directory Users and Computers with adminsitrative credentials
2. Right click on the OU where you want to delegate the ability to enable and disable user accounts
3. Select the Active Directory security group that you want to delegate the ability to and press Next
4. Select Create Custom Task to Delegate and press Next
5. Under Delegate Control Of select the Only the following objects in the folder radio button
6. Select the User objects check box and press Next
7. Under Show these permissions uncheck General and select Property-specific
8. Select the Read userAccountControl and Write userAccountControl check boxes and press Next and Finish

I was troubleshooting a Blackberry Manager problem today that required the BES MDS credentials.  The admin thought he knew what the credentials were, but wasn’t sure.  So I wrote the following SQL query and ran it against the Blackberry Enterprise Server’s BesMgmt database to get the user name and password:  

I setup our help desk users to be able to restore documents using Microsoft’s Volume Shadow Copy client on remote servers yesterday.  Everything worked just fine for me as an administrator, and for users who owned the files, but it didn’t work for the help desk folks.  I found out they didn’t have NTFS rights to the files and folders, so I assumed all I had to do was assign them change permissions, and they’d be able to do the restore.

I made the permission change, but when the help desk folks tried to view the contents of the shadow copy snapshots they received “Access Denied” errors.  I had them confirm they could UNC to the location where the snapshots were located, and they could create and delete files there.

After much Googling didn’t provide many troubleshooting ideas, I decided to manually create a snapshot of the same volume.  I had them test again, and they were able to view the snapshot’s contents and restore files.  Underlying cause was the help desk group didn’t have permissions to the original snapshot, so they couldn’t see the files to restore them.  Hope this helps someone else out.

I was attempting to load a rather large web page on my Blackberry today, and received  the following error:

1. Open Blackberry Manager, selected the affected Blackberry Enterprise Server (BES).
2. Highlight servername_MDS-CS_1
3. Select the Connections Tab and click Edit Properties > General > Flow Control
4. Increase the KB/Connection setting (maximum is 1024, or 1MB)
5. Restart the Blackberry MDS Connection Service

Found the following messages in my Blackberry Enterprise Server 4.1.6 MAGT log file this morning.  I hadn’t noticed them previously, so I did some digging to find out their origin.

CheckNewMbSyncRecords() MISSED MAIL ITEM ARRIVED FOR INACTIVE OR NON-EXISTANT USER, Id=73

CALENDAR UPDATE REQUESTED FOR INACTIVE OR NON-EXISTANT USER, Id=73

Wrote a quick SQL query that I ran against the Besmgmt database to find out who was user ID 73. 

SELECT     Id, DisplayName, UserName
FROM         UserConfig
WHERE     (Id = ‘73′)

The results returned were:

73 Amy Jones ajones

I verified that Amy Jones was still listed as a user in Blackberry Manager.  She was, so I looked at her Groupwise account.  Apparently our User Access group had disabled her Groupwise account while she was on leave from the company.  Disabling the account is what caused the above entries in the log files.

Windows Server 2003 R2 error message

Specific Error Message shown in the Groupwise 7.0.3HP2 WebAccess log file: