Ошибка dfsmapcacheadd domain 0x8007054b

That amazing moment amazing amazing moment when you are able to resolve a long pending issue even that the TechNet forum was all baboons about it.

Having issues with management of your once applied quotas via File Server Resource Manager (FSRM) on your WIndows Server 2008 R2 SP2. Apparently the following can be the reasons for this error:

• You have installed the FSRM role; created quotas; un-installed the FSRM role and re-installed it.
• You have installed the FSRM as a Windows Feature instead of a Role.

And you will be apparently having these following errors/warnings in your Event Viewer:

• Warning 12317:  File Server Resource Manager failed to enumerate share paths or DFS paths. Mappings from local file paths to share and DFS paths may be incomplete or temporarily unavailable. FSRM will retry the operation at a later time.
• Error: DfsMapCacheAdd(Domain), 0x8007054b, The specified domain either does not exist or could not be contacted.
• Error 8197:  File Server Resource Manager Service error: Unexpected error.
• Error: CGlobalStoreManager::Install(), 0x80070005, Access is denied.

Now when you access the Quota tab from the FSRM MMC; you get the an error and no quotas are visible. Or you apply a quota on a folder but instead you get an error saying that the quota for the folder already exists but you don’t see any.

This is apparently due to the fact that the system files associated with the FSRM either get corrupted or the SYSTEM account access is restricted to these files or the previously installed FSRM role settings are still not completely removed.

Now the work around to this issue depends upon how bad have you played with your FSRM role. Just to let you know that This workaround will remove all your previously implemented quota rules and templates.

The work around to this is basically deleting the system files related to the FSRM. Before doing that; uninstall the FSRM Role or the FSRM Feature you installed previously.

Now to delete the FSRM related system files; you won’t be able to access them with you Admin credentials (even Enterprise Admin is not able to alter these files). Only the SYSTEM account has access to it.

Now to access these files here is a small tool; rather set of tools I used. Download the PSTools and follow the following steps.

1. Unzip the downloaded PSTools.
2. Run Command Prompt as Administrator.
3. Navigate to the folder where you unzipped the PSTools.
4. Execute the following command

PSEXEC -i -s -d CMD

Click YES if you have executed the command for the first time. A new Command Prompt window will be opened which basically is running under the privileges of the SYSTEM Account.

Now what you need to do is first delete a couple of files from inside the partition on which you have applied quotas before.   If you have quotas applied on multiple partitions then you will need to repeat the following steps for all the partitions.

What you will basically do is delete the files quota.xml and quota.md from the %SystemVolumeInformationSRM folder. These two system files will be write-protected hence you will need to alter the rights before deleting them.

In the newly opened Command Prompt window; execute the following commands but do not close the windows yet after these commands.

cd System Volume InformationSRM
attrib quota.xml -s -h
attrib quota.md -s -h
del quota.xml
del quota.md

Along these files you will also need to delete the files ReportSettings.xml and SrmGlobalSettings.xml inside the root drive (i.e. C:) %SystemVolumeInformationSRMSettings folder. In the same Command Prompt window opened earlier; execute the following commands.

cd System Volume InformationSRM
attrib ReportSettings.xml -s -h
attrib SrmGlobalSettings.xml -s -h
del ReportSettings.xml
del SrmGlobalSettings.xml

After deleting these system files; install the FSRM Role again; this time hopefully you will be able to install the FSRM Role without any errors. If not then feel free to leave a message! Cheerio!!

References: 

• Getting a CMD prompt as SYSTEM in Windows Vista and Windows Server 2008.
• You cannot create quotas on File Server Resource Manager (FSRM) in Windows Server 2003 R2 KB 555941.

Tags: 0x80070005, 0x8007054, 0x8007054b, Access is denied., DfsMapCacheAdd(Domain), Error 8197, Error: CGlobalStoreManager::Install(), File Server Resource Manager, File Server Resource Manager Service error: Unexpected error., FSRM, FSRM Error, Quota Error, quota.md, quota.xml, ReportSettings.xml, SRM, SrmGlobalSettings.xml, SYSTEM Account, SystemVolumeInformationSRM, Warning 12317, Windows SYSTEM Account

This entry was posted on October 3, 2013 at 9:53 PM and is filed under ADMIN$, ICT, Pakistan, Trends & Tech, Uncategorized, Windows, Windows Server 2008 R2. You can follow any responses to this entry through the RSS 2.0 feed.
You can leave a response, or trackback from your own site.

During a windows 10 Task Sequence upgrade (Wipe and load from Win7), after every restart step in TS, we see there are lot of Socket failed error. The worrying part is in the logs it says it cannot find MP for few seconds and it continues. Sometime this process completes and it fails too.

Log snippet

Current Management Point is <empty>
connect (sock, (struct sockaddr *) &SockAddrIn, sizeof (struct sockaddr_in)) == 0, HRESULT=8007274d (e:cm1706_rtmsmsframeworkosdmessaginglibsmsmessaging.cpp,850)
socket ‘connect’ failed; 8007274d
Failed to connect to MP :80
connect (sock, (struct sockaddr *) &SockAddrIn, sizeof (struct sockaddr_in)) == 0, HRESULT=8007274d (e:cm1706_rtmsmsframeworkosdmessaginglibsmsmessaging.cpp,850)
socket ‘connect’ failed; 8007274d
Failed to connect to MP :443
connect (sock, (struct sockaddr *) &SockAddrIn, sizeof (struct sockaddr_in)) == 0, HRESULT=8007274d (e:cm1706_rtmsmsframeworkosdmessaginglibsmsmessaging.cpp,850)
socket ‘connect’ failed; 8007274d
Failed to connect to MP :80
connect (sock, (struct sockaddr *) &SockAddrIn, sizeof (struct sockaddr_in)) == 0, HRESULT=8007274d (e:cm1706_rtmsmsframeworkosdmessaginglibsmsmessaging.cpp,850)
socket ‘connect’ failed; 8007274d
Failed to connect to MP :443
connect (sock, (struct sockaddr *) &SockAddrIn, sizeof (struct sockaddr_in)) == 0, HRESULT=8007274d (e:cm1706_rtmsmsframeworkosdmessaginglibsmsmessaging.cpp,850)
socket ‘connect’ failed; 8007274d
Failed to connect to MP :80
connect (sock, (struct sockaddr *) &SockAddrIn, sizeof (struct sockaddr_in)) == 0, HRESULT=8007274d (e:cm1706_rtmsmsframeworkosdmessaginglibsmsmessaging.cpp,850)
socket ‘connect’ failed; 8007274d
Failed to connect to MP :443

Changed IP for wireless dhcp assignments, completely different first octet (not the network guy so won’t be able to answer much about this).

Most the clients seemed to adapt, but then a third no longer want to work. Reinstalling the client using a powershell script seems to work but I don’t feel comfortable running that on a massive scale.

Does this seem like a boundary issue even with there just being one boundary based on active directory membership? I found this in another topic:

Resolution:

Stop the ccmexec service

Delete the folowing folders:

c:windowssystem32GroupPolicy

c:windowssystem32GroupPolicyUsers

The GroupPolicyUsers folder may not exist

The GroupPolicy folder may be a hidden folder, ensure view hidden is enabled

Start the ccmexec service

The necessary folders will be recreated, give it a few minutes and the client should receive the boundary group information.

Let me know what to look for, if a relevant server log is known. A check on policy and ccmexec logs didn’t show any issues, but maybe there are other client logs to look at.

Hello everyone. Today, we’re going to investigate the error message ‘No domain controller is available for the specified domain or the domain does not exist: 0x8007054b‘ when trying to turn a domain-joined device into Hybrid Azure AD Joined.

Scenario: Azure AD Hybrid Device Join  

In this article, we’ll focus on the error message, but if you are looking for the requirements and steps to implement Azure Ad Hybrid Device Join, please check this Official Microsoft implementation guide.

Checking device registration status

Prior to the Hybrid Join implementation, once you run the command dsregcmd /status on a windows 10 domain-joined machine, you may face the device state as below:

+———————————————————————-+
| Device State |
+———————————————————————-+

         AzureAdJoined : NO
      EnterpriseJoined : NO
          DomainJoined : YES
            DomainName : CORP
           Device Name : WS10-Hybrid.corp.contoso.com

In case you have DomainJoined is YES, and AzureAdJoined set to NO, means the device is currently joined to the OnPrem Active Directory only.

For more information about all parameters in the output, please check this Microsoft Official document.

Issue: You have implemented all steps and your domain-joined devices still don’t show AzureAdJoined as YES.
You face error message AD Connectivity Test : FAIL when running dsregcmd /status.

Investigating the issue

There are some events and tools that can be used to investigate device join process in the client. We are going to use below ones:
– Utility dsregcmd
– Event viewer log Microsoft-Windows-User Device Registration/Admin

Dsregcmd diagnostic data

Running dsregcmd /status using a command prompt in one affected machine, you can see in the Diagnostic Data that connectivity to OnPrem AD is failing. The failing phase is the pre-check. This is when the device runs all requirements to trigger the Azure AD automatic join process.

+———————————————————————-+
| Diagnostic Data |
+———————————————————————-+

 Diagnostics Reference : www.microsoft.com/aadjerrors
          User Context : SYSTEM
           Client Time : 2022-06-07 16:58:32.000 UTC
  AD Connectivity Test : FAIL
 AD Configuration Test : SKIPPED
    DRS Discovery Test : SKIPPED
 DRS Connectivity Test : SKIPPED
Token acquisition Test : SKIPPED
 Fallback to Sync-Join : ENABLED

 Previous Registration : 2022-06-07 16:41:09.000 UTC
           Error Phase : pre-check
      Client ErrorCode : 0x1

By default, once you have all steps to the Hybrid Join in place, the user sign-in triggers the Automatic Device Join task. The Automatic Device Join tasks is triggered on domain join and retried every hour. You can also open the command prompt as administrator and run command dsregcmd /debug /join.

You may face output similar to this one:

C:Usersulyneves>dsregcmd /debug /join

DsrCLI: logging initialized.
DsrCLI: logging initialized.
DsrCmdJoinHelper::Join: ClientRequestId: 08f70efe-0f59-4856-8ddd-XXXXXXXXdeDsrCmdAccountMgr::IsDomainControllerAvailable: DsGetDcName No domain controller is available for the specified domain or the domain does not exist: 0x8007054b.
PreJoinChecks Complete.
preCheckResult: DoNotJoin
deviceKeysHealthy: undefined
isJoined: undefined
isDcAvailable: NO
isSystem: YES
keyProvider: undefined
keyContainer: undefined
dsrInstance: undefined
elapsedSeconds: 11
resultCode: 0x1
The device can NOT be joined because a domain controller could not be located.

Now, checking the Event viewer log Microsoft-Windows-User Device Registration/Admin with event ID 334, we can confirm the device is lacking communication with OnPrem AD:

Automatic device join pre-check tasks completed.

The device can NOT be joined because a domain controller could not be located. The device must be connected to a network with connectivity to an Active Directory domain controller.

REASON: With the events above, it’s clear that we have a lack of communication between the device and the domain controller, which is a requirement to have a successful automatic Hybrid Azure AD Join.

As per Microsoft’s official documentation, we conclude the failure is occurring in the pre-check phase. Step B where is explained: The task queries Active Directory using the LDAP protocol for the keywords attribute on the service connection point stored in the configuration partition in Active Directory (CN=62a0ff2e-97b9-4513-943f-0d221bd30080,CN=Device Registration Configuration,CN=Services,CN=Configuration,DC=corp,DC=contoso,DC=com). The value returned in the keywords attribute determines if device registration is directed to Azure Device Registration Service (ADRS) or the enterprise device registration service hosted on-premises.

FIX: Make sure your Hybrid joined machine has proper connectivity to a domain controller to have a successful LDAP query.

Considering I blocked the communication to reproduce the issue, after removing the firewall rule and restoring the connectivity between the client and the domain controller, the join process is successful as below:

Join request ID: 979d242b-57de-4749-a84d-XXXXXXXX
Join response time: Tue, 07 Jun 2022 17:15:03 GMT
Join HTTP status: 200
DsrCmdJoinHelper::Join: completed successfully
DSREGCMD_END_STATUS
AzureAdJoined : YES
EnterpriseJoined : NO
DeviceId : f4caef4d-c69b-44e5-b1ff-919010c2699c
Thumbprint : XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
DeviceCertificateValidity : [ 2022-06-07 16:45:04.000 UTC — 2032-06-07 17:15:04.000 UTC ]
KeyContainerId : ce7d06f2-05c5-4b6b-b528-XXXXXXXXXXX
KeyProvider : Microsoft Software Key Storage Provider
TpmProtected : NO
DeviceAuthStatus : SUCCESS

And we confirm with the output of command dsregcmd /status, that the affected device has both Azure DomainJoined and AzureAdJoined set to YES.

+———————————————————————-+
| Device State |
+———————————————————————-+

         AzureAdJoined : YES
      EnterpriseJoined : NO
          DomainJoined : YES
            DomainName : CORP
           Device Name : WS10-Hybrid.corp.contoso.com

Checking the same event viewer log Microsoft-Windows-User Device Registration/Admin in the event viewer, we can confirm with event ID 306 that Automatic registration succeeded.

Summary

In this article, we covered how to investigate the error message ‘No domain controller is available for the specified domain or the domain does not exist: 0x8007054b‘ when trying to turn a domain-joined device into Hybrid Azure AD Joined.

I hope you have enjoyed reading this article, and it helps you manage your Hybrid devices in Azure AD.

Enjoyed the article? Like and share. 🙂

Note: I do not represent the organization I work for, all the opinions expressed here, are my own. This post is provided AS IS with no warranties or guarantees and confers no rights.

In case you have any suggestions or feedback, please leave a comment.

[ ]’s
Ulysses Neves

Hello!

I’ve got a strange issue with Internet Based Client Management where clients are not communicating when outside of the network.

Some interesting things I’ve found in client side logs:

LocationServices.log:

1 internet MP errors in the last 10 minutes, threshold is 5.

In CCMMessaging.log, I’m seeing a few of these:

Post to https://----sccm-01.-------------.org/ccm_system/request failed with 0x87d00231.

Interesting Server Side Logs:

ClientAuth.log:

Error verifying message from client 'GUID:736B0572-FF7D-45BD-84D2-5E5C6C6F6EC8' (0x80090006).
Message from GUID:abb9de52-52f6-42fa-8901-9e65513e5faf client failed signature validation
Skipping raising MPEvent_ClientAuth_SignatureFailure event because 4 such events were already raised in the past 60 minutes
Could not verify message signature for client 'GUID:abb9de52-52f6-42fa-8901-9e65513e5faf'.

ClientLocation.log

Raising pending event:
instance of CCM_LocationServices_LocationBaseChange
{
ClientID = "GUID:abb9de52-52f6-42fa-8901-9e65513e5faf";
DateTime = "20160610201145.755000+000";
NewLocation = "Internet";
OldLocation = "Intranet";
ProcessID = 3264;
ThreadID = 1464;
};


Unable to retrieve AD forest + domain membership. Error 0x8007054b

Some background on the environment:

• Single server with all roles and SQL (~6,000 clients), 32 GB ram, 24 cores. All clients are well connected — no slow links.
  • Upgraded existing server from SCCM 2012 R2 CU5 to SCCM 1511, then to 1602, then did a backup/restore onto new hardware to get the server from 2008 R2 to 2012 R2
• Two domains, both have Discovery Methods set up in SCCM, and clients are working internally
• Newly configured three-tier CA: Offline root Standalone CA, one subordinate issuing Enterprise CA
  • CRL and AIA is published over HTTP. Both CRL and AIA are internet accessible.
  • Group Policy for Trusted Root certificate, and client auto enrollment are both configured.
  • All clients in both domains have the Offline Root Cert in the Computer Accounts Trusted Root store.
  • All clients in both domains are being issued SCCM Client authentication Certs from the CA
  • SCCM Server’s DP cert is installed,
• SCCM DNS is published internally and externally with the same name. NATs and ACLs are working on the firewall, and the mplist test methods do return valid XML internally and externally

Where else should I look to troubleshoot / diagnose?

It almost seems like something with the CA / certs installed, but I *think* they’re correct…

Has anyone else had similar issues with IBCM, and how did you fix it?

Any help / guidance would be appreciated!

Thanks!

Within a ConfigMgr Current Branch environment with multiple untrusted forests, the following error message was seen in Site and System status: Active Directory System Discovery Agent failed to bind to container LDAP. This on every 5 minutes (delta discovery).

—Error: The specified domain either does not exist or could not be contacted.
—Possible cause: The AD container specified earlier might be invalid now. The Domain Controller is inaccessible.
—Solution: Please verify that the AD container paths specified are valid. Confirm accessibility of the site server to the Domain Controller to be queried.

Looking in adsysdis.log error 0x8007054B is given:
—ERROR: Failed to bind to LDAP://OU=Test,DC=Contoso,DC=local (0x8007054B)
—ERROR: Failed to enumerate directory objects in AD container LDAP://OU=Test,DC=Contoso,DC=local

When looking in Active Directory System Discovery the following was configured: LDAP://OU=Test,DC=Contoso,DC=local (for example)
This for every untrusted forest given..

When looking in sitecomp.log however the following was seen:
-Processing forest contoso.local.
-Publishing account user account <Domain><Account> will be used
-DS Root:DC=Contoso,DC=local
-Searching for the System Management Container.
-LDAP://Contoso.local/CN=System Management,CN=System,DC=Contoso,DC=local container exists.

So yes, there must be an extra FQDN step in between.
Just change LDAP://OU=Test,DC=Contoso,DC=local to LDAP://Contoso.local/OU=Test,DC=Contoso,DC=local for every untrusted forest in Active Directory System Discovery and you will be fine. (for example)

Looking in adsysdis.log again will show the following information:
—INFO: Bound to LDAP://Contoso.local/OU=Test,DC=Contoso,DC=local
—INFO: successfully completed directory search
—INFO: Start to recursively process into group objects
—INFO: Finished recursively processing into group objects

So no errors in adsysdis.log and Site and System status seen anymore. Very happy with the solution!

Source: Anoop C Nair