Thursday, May 30, 2013

02A2: BMC System Error Log (SEL) Full.

A customer of mine had a HP ProLiant ML110 G6 server which did not boot successfully.  Upon booting the boot would halt with the following error message:

02A2: BMC System Error Log (SEL) Full.


The fix for this problem was to go into the BIOS by hitting F10 and setting Clear System Event Logs to Enabled in the BIOS.

This can be found under IPMI on the Advanced Tab.


Navigate to System Event Log


And setting the Clear System Event Log to Enabled.  This will ensure the event log is cleared on next boot.  As you see there are no remaining event logs in our BIOS flash memory hence why the error is occurring.


Upon reboot the system will automatically set Clear System Event Log back to Disabled after the clear has been performed.

Monday, May 27, 2013

Schemus - User synchronization failed. Update abandoned

One of my customers who utilises Symantec Cloud email and web filtering was experiencing an issue with the Schemus synchronisation tool when synchronising Mail Address, Groups and Users to Symantec Cloud.

The error they were experiencing was:

User synchronization failed. Update abandoned


After speaking to Symantec this issue can occur sometimes with Schemus due to corruption in one of the following files:
  • users.sus
  • syncdata.sus
  • groups.sus
These files are located in the following directory:

C:\ProgramData\Schemus\configurations\SYNCJOBNAME

In our case it was:

C:\ProgramData\Schemus\configurations\SymantecADSync

To fix this problem, first close Schemus.

Next rename or move these files to another location.

Lastly reopen Schemus and attempt another sync, these files will regenerate.  After making this change Synchronisation is now working correctly.

 

Sunday, May 26, 2013

CloudLink - The current account doesn't have sufficient privileges

In the process of setting up Symantec Enterprise Vault Cloud for Microsoft Exchange, I had an issue where the ArchiveTools CloudLink tool would not accept my service account I created called cloudlink.  It is complaining the account does not have Logon As Service privileges on my CloudLink server however I know the account does as I already granted this User Rights Assignment manually.

The error we were getting was:

CloudLink - The current account doesn't have sufficient privileges to give 'Logon As Service' privilege to the selected account. An administrator will need to manually allow this account to run as service.  Failing to do so will prevent the service from running.


The problem?  Good old User Account Control or UAC for short.

After trying again by running ArchiveTools CloudLink  as "Run as Administrator" the problem was resolved.

 

Wednesday, May 22, 2013

You don't currently have permission to access this folder

With the introduction of Windows Vista came the first implementation of User Account Control (UAC) and with it, a file server NTFS permission issue which has been driving me nuts for years.  If you are a Windows server admin you have probably seen this too but never thought twice.

When accessing a folder on a Windows file server, it prompts saying "You don't currently have permission to access this folder".  Now I know this folder has the following permissions set on it:
  • SYSTEM - Full Control
  • Administrators - Full Control
  • Users - Create Folder append data
My user account is a member of Domain Admins and I know that Domain Admins is nested in the Administrators group on the file server.  I should have permission to access this folder.


If I click continue to this prompt, UAC will automatically add my user name with full control permissions to the folder and all sub folders and files which I'm attempting to access.  With multiple administrators maintaining a file server this results in unwanted user name ACL's spread across folders and files throughout the file server making the permission structure a mess.

After many years and now with the release of Windows Server 2012 this issue is still occurring.  It's about time we spend some time and work out what's going on.

Resolution

After leasing with some colleagues of mine in Microsoft who work on the file services team they told me three group policy settings are responsible for this behaviour which can be found under:

Computer Configuration --> Windows Settings --> Security Settings --> Local Policies --> Security Options
  • User Account Control: Admin Approval Mode for the Built-in Administrator account
  • User Account Control: Behaviour of the elevation prompt for administrators in Admin Approval Mode
  • User Account Control: Run all administrators in Admin Approval Mode
Set the policies settings as follows in the following order as per the screenshot below:
  • Disabled
  • Elevate without prompting
  • Disabled
 
You don't have to create a group policy object to implement these changes unless you have multiple file servers you want to target.  In this instance I simply utilised GPEDIT.MSC on the local file server and set these changes as a local policy.

Now when my administrators navigate the file server they are no longer prompted to add their account to NTFS permissions and in result making a mess of my NTFS permission structure.

AD Replication Issue - The naming context is in the process of being removed or is not replicated from the specified server

I had an Active Directory replication problem at a customer site with a multi domain environment.  Two domain controllers exists in a child domain called DC1 and DC2.  DC1 resided in a remote branch location and DC2 exists in a datacentre.
  • DC2 was able to replicate changes to DC1 without issues.
  • DC1 was not able to replicate changes to DC2.
Please note the name of the domain and domain controllers involved have been renamed to protect customer privacy.
Symptoms

When attempting a manual replication attempt the following error was experienced:

The following error occurred during the attempt to synchronize naming context "ROOT DOMAIN" for domain controller DC1 to domain controller DC2:

The naming context is in the process of being removed or is not replicated from the specified server.

The operation will not continue.

 

When doing repadmin /showrepl all inbound replication partners came back successful under the last replication attempt however all outbound replication partners such as the replication attempt from DC1 to DC2 came back as failed with the following errors:

 Source: RemoteSiteName\DC1
******* 216 CONSECUTIVE FAILURES since 2013-04-21 07:32:26
Last error: 8524 (0x214c):
            Can't retrieve message string 8524 (0x214c), error 1815.


Naming Context: CN=Configuration,DC=ROOTDOMAIN,DC=LOCAL
Source: RemoteSiteName\DC1\
******* WARNING: KCC could not add this REPLICA LINK due to error.


Naming Context: DC=CHILDDOMAIN,DC=ROOTDOMAIN,DC=LOCAL
Source: RemoteSiteName\DC1
******* WARNING: KCC could not add this REPLICA LINK due to error.


Running a DCDiag on DC1 came back with the following errors:

Starting test: Connectivity

The host 9b2163cf-b8e7-4ad4-bd54-2342e6cfc1db._msdcs.rootdomain.local could not be resolved to an IP address.  Check the DNS server, DHCP, server name etc.

Although the GUID DNS name 9b2163cf-b8e7-4ad4-bd54-2342e6cfc1db._msdcs.rootdomain.local couldn't be resolved, the server name (DC1.child.rootdomain.local) resolved to the IP address xx.xx.xx.xx and was pingable.  Check that the IP address is registered correctly with the DNS server.


Resolution

The following error message is the one which lead me to the resolution of this replication issue.

The host 9b2163cf-b8e7-4ad4-bd54-2342e6cfc1db._msdcs.rootdomain.local could not be resolved to an IP address.  Check the DNS server, DHCP, server name etc.

Although the GUID DNS name 9b2163cf-b8e7-4ad4-bd54-2342e6cfc1db._msdcs.rootdomain.local couldn't be resolved, the server name (DC1.child.rootdomain.local) resolved to the IP address xx.xx.xx.xx and was pingable.  Check that the IP address is registered correctly with the DNS server.

The first domain you promote in a new Active Directory forest is the forest root domain (this can never be changed without building a new forest).  The forest root domain contains a MSDCS container in DNS and contains a bunch of CNAME records for all domain controllers in the root domain as well as any child domains/new tree domains.  These CNAME records are what Active Directory uses to lookup domain controllers when attempting to perform replication.

This is shown in the following screenshot.


The reason DC1 was unable to replicate to any other DC in the domain was because someone deleted the GUID mapping the CNAME record for DC1 from the msdcs container in Active Directory.  From the DCDIAG error message we manually recreated the 9b2163cf-b8e7-4ad4-bd54-2342e6cfc1db._msdcs.rootdomain.local record mapping to DC1 as a CNAME record. 

After 45 minutes replication began working again for DC1.

Hope this post helps someone with the same problem.

Sunday, May 12, 2013

WSUS - An HTTP error occured

In the process of setting up a new WSUS server I received the following error message when attempting to perform a sync.  This is after installing WSUS 3.0 Service Pack 2 available from http://support.microsoft.com/kb/2720211

An HTTP error occurred

Clicking Details provides the following error output.

WebException: The request failed with the error message:
--
Object moved
Object moved to %2fmicrosoftupdate%2fv6%2ferrorinformation.aspx%3ferror%3d15"

--.
at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyncCall)
   at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters)
   at Microsoft.UpdateServices.ServerSyncWebServices.ServerSync.ServerSyncProxy.GetAuthConfig()
   at Microsoft.UpdateServices.ServerSync.ServerSyncLib.InternetGetServerAuthConfig(ServerSyncProxy proxy, WebServiceCommunicationHelper webServiceHelper)
   at Microsoft.UpdateServices.ServerSync.ServerSyncLib.Authenticate(AuthorizationManager authorizationManager, Boolean checkExpiration, ServerSyncProxy proxy, Cookie cookie, WebServiceCommunicationHelper webServiceHelper)
   at Microsoft.UpdateServices.ServerSync.CatalogSyncAgentCore.SyncConfigUpdatesFromUSS()
   at Microsoft.UpdateServices.ServerSync.CatalogSyncAgentCore.ExecuteSyncProtocol(Boolean allowRedirect)



After researching this error message I discovered Microsoft moved data on the Microsoft Update servers early 2013 and as a result the WSUS installation package which comes with Windows Server 2008 R2 no longer knows the correct URL to synchronise with (this is after installing WSUS 3.0 SP2 from KB2720211).

After installing WSUS 3.0 SP2 from KB2720211 you then must install another critical update which can be downloaded from KB2734608.  This will tell WSUS the new location to synchronise from.  In total you should have installed the following two updates including the Report Viewer 2008 package.

Download KB2734608: http://support.microsoft.com/kb/2734608


After installing KB2734608 on my WSUS 3.0 Service Pack 2 server, WSUS now referenced the right Microsoft Update location and synchronisation started working successfully.


 

Windows Update Error 80244018

Today I had issues patching a Windows Server 2008 R2 server at one of my clients.  Windows Update provided me with the following error message:

A error occurred while checking for new updates for your computer.
Error Code 80244018

 
This error code is generated when a computer has issues connecting to the Windows Update server.  My customer used Threat Management Gateway as a firewall solution.  After reviewing the firewall rules there was a rule which prevented access to Microsoft Windows Update servers.

Removed the rule and problem resolved.