Anything for sysadmins!


Event 5555 – No User Profile Application available to service the request

I was troubleshooting some problems with the User Profiles Service of SharePoint 2010 and I ran into event ID 5555. The error seems to be reoccurring every day around 6:11 AM.

Failure trying to synch web application e888f5cd-9e4b-4396-a693-2e81ba156b0b, ContentDB 33167fc6-5268-4acc-aac2-f4b2aaf789f7 Exception message was Microsoft.Office.Server.UserProfiles.UserProfileApplicationNotAvailableException: No User Profile Application available to service the request. Contact your farm administrator.
at Microsoft.Office.Server.Administration.UserProfileApplicationProxy.get_ApplicationProperties()
at Microsoft.Office.Server.Administration.UserProfileApplicationProxy.get_PerfmonInstanceHandle()
at Microsoft.Office.Server.UserProfiles.ContentDBSynchronizer..ctor(ELogType logType, SPContentDatabase cdb, SPJobState jobState)
at Microsoft.Office.Server.UserProfiles.WSSProfileSyncJob.Execute()

This error occurs as it's colliding with another job that's running at that time. The fix is quite easy, change the job time so it doesn't collide.

  1. Log into the SharePoint 2010 Central Administration
  2. Click Monitoring
  3. Click Review Job Definitions
  4. Go to the second page click on the Timer Service Recycle
  5. Change the start time and the no later than time to 6:30 PM
  6. Click OK

It's smart to check the event viewer the next day to make sure that the problem has been resolved.


Event 58 – The disk signature of disk n is equal to the disk signature of disk n

Log Name: System
Source: partmgr
Event ID: 58
Task Category: None
Level: Warning
The disk signature of disk 2 is equal to the disk signature of disk 0.

This error occurred on one of the virtual machines on the ESX environment. It probably also caused another error a bit further up in the event viewer.

Log Name: System
Source: VDS Basic Provider
Event ID: 1
Task Category: None
Level: Error
Unexpected failure. Error code: D@01010004

Disk 0 is the system disk, which contains the Windows 2008 R2 installation. Disk 2 on the other hand is non-existent, or better said, hidden. This error can easily cause errors with your backup software like Backup Exec.

You can also run into this error when you're using Hyper-V and you're making a backup using Backup Exec by means of the Hyper-V agent. It will then mount the virtual machine disk on the host server. If the host server disk and the virtual machine disk have the same disk ID they will clash causing event id 58.

If you do the following, you can get the current disk ID:

  1. Start a cmd as administrator
  2. Type:
  3. Type:
    list disk
  4. Type:
    select disk 0

    (replace the 0 with the disk indicated in Event ID 58)

  5. Type:
    detail disk

As you can see, my disk ID is 3B9ED7B7. This seems to clash with another hidden disk that has the same disk ID. To change the disk ID you'll have to download the Windows 2000 resource kit or if you can find it with Google dumpcfg.exe or dumpcfgx64.exe if you're on 64-bit.

Once you've downloaded the utility you'll have to start a cmd as administrator, and run the utility with the parameters -S followed directly with the new disk ID, a space and the number of the disk that you used in the select disk command above.

  1. Start a cmd as administrator
  2. Type:
    dumpcfgx64.exe -S3B9ED7B8 0
  3. Or use diskpart and select disk (ID) then type:
    uniqueid disk id=3B9ED7B8

When you follow the procedure to get your disk ID again you'll notice that it's been changed to the new value.


SharePoint 2010 Trusted Identity Token Issuer Error

I was setting up SharePoint to use Federated Authentication using Azure Access Control Service (ACS) when it ran into an error. After checking the SharePoint logs I ran into the following lines:

07/15/2011 10:23:36.54     w3wp.exe (0x1670)     0x0C60    SharePoint Foundation     Claims Authentication     eu2n    Monitorable    Trusted login provider 'Public Account' is not sending configured input identity claim type ''    

07/15/2011 10:23:36.54     w3wp.exe (0x1670)     0x0C60    SharePoint Foundation     Monitoring     b4ly    High     Leaving Monitored Scope (SPSecurityTokenService.GetTokenLifetime()). Execution Time=125,240686737495    

07/15/2011 10:23:36.56     w3wp.exe (0x1670)     0x0C60    SharePoint Foundation     Claims Authentication     fo1t    Monitorable    SPSecurityTokenService.Issue() failed: System.ServiceModel.FaultException: The trusted login provider did not supply a token accepted by this farm. at Microsoft.SharePoint.IdentityModel.SPSecurityTokenService.SPRequestInfo.ValidateTrustedLoginRequest() at Microsoft.SharePoint.IdentityModel.SPSecurityTokenService.SPRequestInfo..ctor(IClaimsIdentity identity, RequestSecurityToken request, Boolean initializeForActor) at Microsoft.SharePoint.IdentityModel.SPSecurityTokenService.SPRequestInfo..ctor(IClaimsPrincipal principal, RequestSecurityToken request) at Microsoft.SharePoint.IdentityModel.SPSecurityTokenService.GetTokenLifetime(Lifetime requestLifetime) at Microsoft.IdentityModel.SecurityTokenService.SecurityTokenService.Issue(IClaimsPrincipal principal, RequestSecurityT...    

07/15/2011 10:23:36.56*    w3wp.exe (0x1670)     0x0C60    SharePoint Foundation     Claims Authentication     fo1t    Monitorable    ...oken request) at Microsoft.SharePoint.IdentityModel.SPSecurityTokenService.Issue(IClaimsPrincipal principal, RequestSecurityToken request)

Also the event viewer returned the following error:

Log Name: Application

Source: Microsoft-SharePoint Products-SharePoint Foundation

Date: 15-7-2011 10:23:36

Event ID: 8306

Task Category: Claims Authentication

Level: Error


User: DOMAIN\user

Computer: sharepoint.domain.local


An exception occurred when trying to issue security token: The trusted login provider did not supply a token accepted by this farm..

Quite obviously when I select Windows Live ID it doesn't return the expected type of claim; namely


In Azure ACS you can set what type of data is retrieved and also what type it returns. The Windows Live ID Identity Provider doesn't support email address as a claim type, however you can map the only available input claim type to any other type that you use to validated the incoming claim in SharePoint.

My SharePoint environment is setup to allow validation through emailaddress. I'll have to map the '' claim type to the '' claim type as shown below.

  1. Navigate to your Azure ACS URL (https://<ServiceNamespace>
  2. Click Rule groups
  3. Click the Rule group that is used by your SharePoint environment
  4. Click on the only entry with Windows Live ID as Claim Issuer
  5. Check Select Type in the Then section and select the proper claim type ( that SharePoint is expecting
  6. Click Save and check the results

Now try to log in to your SharePoint environment with the Windows Live ID and it should work flawlessly.

One thing to note is that the login name is an odd string of characters instead of a nicely structured email address. Unfortunately there is no way of getting a nice looking login name using Windows Live ID as there is no other option than returning the nameidentifier. This seems kind of odd since it's a Microsoft product and the most restricted Identity provider is also from Microsoft. I hope that Microsoft will add other options soon.


DNS doesn’t resolve on Windows 2008

Someone asked me why the domain wasn't working on our network. IE was returning that it couldn't find the server. This soon pointed in the direction of DNS. The nslookup of the domain also failed. The Global Logs in the DNS Manager returned some 5504 events.

The DNS server encountered an invalid domain name in a packet from The packet will be rejected. The event data contains the DNS packet.

After hitting Google with this event it soon gave me a couple of options to solve it. A big thank you goes to Shilpesh Desai! Source

  1. Check following registry key and value set for it:

    According to KB 198410 it should have a non-zero value

  2. Packet was forwarded to non-recursive DNS server. I will recommend to switch to forwarders for few days to check if that helps.
  3. Server is quering for DNAME record, which is not supported. Reponses containing DNAME (rrtype - 0x0027) record.
  4. Extended DNS (EDNS) packets are received but the server that is attempting to resolve the EDNS traffic doesn't support EDNS or have it enabled. An easy workaround is to disable EDNS.
    dnscmd /Config /EnableEDnsProbes 0

One disadvantage of this solution is that DNSSEC is not possible anymore as this relies on the EDNS principle.

More info on EDNS

More info on DNSSEC


Event 8193 – Volume Shadow Copy Service error

SharePoint Search has its issues sometimes. This one seems to happen to a lot of people, but the solutions that I've found weren't too clear about what to do to solve this. Here's the event that is triggered.

 Volume Shadow Copy Service error: Unexpected error calling routine RegOpenKeyExW(-2147483646,SYSTEM\CurrentControlSet\Services\VSS\Diag,...).  hr = 0x80070005, Access is denied.
</p><p>   Initializing Writer
</p><p>   Writer Class Id: {0ff1ce14-0201-0000-0000-000000000000}
</p><p>   Writer Name: OSearch14 VSS Writer
</p><p>   Writer Instance ID: {07c936a8-347c-4e39-8014-2a057f611382}

If you go to the Details tab, you'll see some additional information about the event.

The part after User and Name is the most important here, which I've blurred for security reasons. This is the account name that needs full control on the registry key HKLM\SYSTEM\CurrentControlSet\Services\VSS\Diag.

  1. Start regedit.exe
  2. Navigate to the key HKLM\SYSTEM\CurrentControlSet\Services\VSS\Diag
  3. Right-click the key Diag and select Permissions
  4. Add the account that was indicated in the event and provide it with Full control permission

Event 2937 – HomeMTA pointing to the Deleted Objects container

Recently I came across the following warning.

 Log Name: Application<br/>Source: MSExchange ADAccess<br/>Date: 23-9-2010 17:06:55<br/>Event ID: 2937<br/>Task Category: Validation<br/>Level: Warning<br/>Keywords: Classic<br/>User: N/A<br/>Computer: exchangeserver.domain.local<br/>Description:<br/>Process powershell.exe (PID=8552). Object [CN=FederatedEmail.4c1f4d8b-8179-4148-93bf-00a95fa1e042,CN=OU,DC=domain,DC=local]. Property [HomeMTA] is set to value [domain.local/Configuration/Deleted Objects/Microsoft MTA DEL:ceb6fb78-f913-4907-9522-3f2f20e20d1a], it is pointing to the Deleted Objects container in Active Directory. This property should be fixed as soon as possible.<br/>Event Xml:<br/>&lt;Event xmlns=""&gt;<br/>&lt;System&gt;<br/>&lt;Provider Name="MSExchange ADAccess" /&gt;<br/>&lt;EventID Qualifiers="32768"&gt;2937&lt;/EventID&gt;<br/>&lt;Level&gt;3&lt;/Level&gt;<br/>&lt;Task&gt;6&lt;/Task&gt;<br/>&lt;Keywords&gt;0x80000000000000&lt;/Keywords&gt;<br/>&lt;TimeCreated SystemTime="2010-09-23T15:06:55.000000000Z" /&gt;<br/>&lt;EventRecordID&gt;49552&lt;/EventRecordID&gt;<br/>&lt;Channel&gt;Application&lt;/Channel&gt;<br/>&lt;Computer&gt;exchangeserver.domain.local&lt;/Computer&gt;<br/>&lt;Security /&gt;<br/>&lt;/System&gt;<br/>&lt;EventData&gt;<br/>&lt;Data&gt;powershell.exe&lt;/Data&gt;<br/>&lt;Data&gt;8552&lt;/Data&gt;<br/>&lt;Data&gt;CN=FederatedEmail.4c1f4d8b-8179-4148-93bf-00a95fa1e042,CN=OU,DC=domain,DC=local&lt;/Data&gt;<br/>&lt;Data&gt;HomeMTA&lt;/Data&gt;<br/>&lt;Data&gt;domain.local/Configuration/Deleted Objects/Microsoft MTADEL:ceb6fb78-f913-4907-9522-3f2f20e20d1a&lt;/Data&gt;<br/>&lt;/EventData&gt;<br/>&lt;/Event&gt;

The process can be anything related to Exchange. I've seen:

  • MSExchangeMailboxAssistants.exe
  • w3wp.exe
  • Microsoft.Exchange.RpcClientAccess.Service.exe
  • Microsoft.Exchange.ServiceHost.exe
  • ExSetupUI.exe
  • powershell.exe

The object can also change. I've seen:

  • Administrator
  • SystemMailbox.<GUID>
  • FederatedEmail.<GUID>

This probably started because I upgraded Exchange 2010 to SP1. Thanks to Kevin Ca I now know how to correct the issue.

In the Exchange Management Shell do a Get-Mailbox to get the mailbox. Use the -Arbitration switch to get the system mailboxes. Then pipe that to Update-Recipient.

[Powershell]Get-Mailbox Administrator | Update-Recipient[/Powershell]

If you're using the -Arbitration switch you might have to further specify the mailbox. An easy way is:

[Powershell]Get-Mailbox -Arbitration | Where {$_.Name -like "SystemMailbox{E3*" } | Update-Recipient [/Powershell]

Running the Update-Recipient cmdlet on a mailbox reinitializes the HomeMTA value and solves the warning message.


Event 10016 – DistributedCom

Although I've seen the DCOM error a lot, the one below needed a different approach than usual.

Log Name: System
Source: Microsoft-Windows-DistributedCOM
Date: 23-8-2010 8:40:12
Event ID: 10016
Task Category: None
Level: Error
Keywords: Classic
Computer: server.domain.local
The application-specific permission settings do not grant Local Launch permission for the COM Server application with CLSID {24FF4FDC-1D9F-4195-8C79-0DA39248FF48} and APPID {B292921D-AF50-400C-9B75-0C57A7F29BA1} to the user NT AUTHORITY\SYSTEM SID (S-1-5-18) from address LocalHost (Using LRPC). This security permission can be modified using the Component Services administrative tool.

Event Xml:
<Event xmlns="">
<Provider Name="Microsoft-Windows-DistributedCOM" Guid="{1B562E86-B7AA-4131-BADC-B6F3A001407E}" EventSourceName="DCOM" />
<EventID Qualifiers="49152">10016</EventID>
<TimeCreated SystemTime="2010-08-23T06:40:12.000000000Z" />
<Correlation />
<Execution ProcessID="0" ThreadID="0" />
<Security UserID="S-1-5-18" />
<Data Name="param1">application-specific</Data>
<Data Name="param2">Local</Data>
<Data Name="param3">Launch</Data>
<Data Name="param4">{24FF4FDC-1D9F-4195-8C79-0DA39248FF48}</Data>
<Data Name="param5">{B292921D-AF50-400C-9B75-0C57A7F29BA1}</Data>
<Data Name="param6">NT AUTHORITY</Data>
<Data Name="param7">SYSTEM</Data>
<Data Name="param8">S-1-5-18</Data>
<Data Name="param9">LocalHost (Using LRPC)</Data>

The event was triggered after installing and enabling the Kaspersky Administration Kit service. After some research I found a post on the Technet forums which told me what to do.

Seems like this error is related to the Network Access Protection Agent service. If this service isn't started, this error will occur. To stop the error change the startup type to automatic and start the service.

Tagged as: No Comments