we are experiencing the following problem:
we have MS SCCM 2007 SP1 R2 central site installed on windows 2008 SP2 enterprise with SQL Server 2008 Enterprise and using internal CA for our AMT machines. We have entered manually the certificate hash in the client machines.
What we experiencing is that we don't see any computer in the AMT OU in AD (it is empty!).
We have successfully provisioned some computers and we can stop and start them using SCCM, but we can't connect to them using the Out of band management console or through the web interface. We have granted full access to the AMT OU and all child objects as required according the documentation for the Primary Site servers group(we have followed Quick Start Install Guide for SCCM SP1 Rev1.9.1 ).
We have made also the required change in the registry according to the KB908209 (for the web based connection) and also tried to start the out of band management console from the central site, where the required patch KB960804 is installed.
A look in the amtopmgr.log give us no error, related to the AMT OU in the AD container. The error in the OOBConsole.log is the following:
GetAMTPowerState fail with result:0x80070035
When we tested the AMT technology in our test environment, we have in the AMT OU the computers which was provisioned.
So if anyone has a clue how can we solve this problem, please let us know.
Thanks in advance.
With best Regards
The problem you are seeing with the out of band console and the amt web console is directly related to the lack of an AMT AD object in the OU. 95% of the time, this issue is directly related to the lack of SCCM Server Object permissions on the AD OU; however, from what you described below, your settings sound correct. During the provisioning process, what does the AMTProxyMgr.log on the primary site server (running the Out of Band Service Point Role) say?
thanks for your answer. We have reprovisioned one of the system in order to reproduce the log. After that looking in the log it has produced the following errors:
CActiveDirectoryUtils::CreateObject - failed to get container.The resource loader cache doesn't have loaded MUI entry.
AD Task - CreateObject failed. FQDN: <FQDN name>, ADDN: OU=Out of Band Management Controllers,OU=Computers,OU=Staging,OU=BG,DC=<suffix>,DC=<suffix>,DC=<suffix>, UUID: 81E49682-C94A-CB11-86BE-CDDFBEF1E458, AMT Version: 4.0.8.
STATMSG: ID=7602 SEV=E LEV=M SOURCE="SMS Server" COMP="SMS_AMT_PROXY_COMPONENT" SYS=<computer name> SITE=<code> PID=10216 TID=1024 GMTDATE=Wed Sep 23 09:58:57.191 2009 ISTR0="<FQDN name>" ISTR1="OU=Out of Band Management Controllers,OU=Computers,OU=Staging,OU=BG,DC=<suffix>,DC=<suffix>,DC=<suffix>" ISTR2="81E49682-C94A-CB11-86BE-CDDFBEF1E458" ISTR3="4.0.8" ISTR4="" ISTR5="" ISTR6="" ISTR7="" ISTR8="" ISTR9="" NUMATTRS=0
Failed to run instruction: ADT CREATE;<FQDN name>;OU=Out of Band Management Controllers,OU=Computers,OU=Staging,OU=BG,DC=<suffix>,DC=<suffix>,DC=<suffix>;
Finished Executing Instruction: ADT CREATE;<FQDN name>;OU=Out of Band Management Controllers,OU=Computers,OU=Staging,OU=BG,DC=<suffix>,DC=<suffix>,DC=<suffix>;
Do you have any idea what can cause them.
Thanks in advance.
If it's an Active Directory issue, I guess my first thoughts are similar to Matt's: permissions, but also DNS. Have you ensured that you can resolve the FQDN of your AD domain from the server running the out of band service point?
Also, back to permissions ... even though you may have added your SCCM site servers to the ACL for that OU, is there possibly another ACE being inhereited, that's explicitly denying some permissions that you think you've granted to the site server(s)? In order to validate that the correct permissions are indeed there, I would suggest going into the Advanced section under the Security tab (on the OU), selecting the Effective Permissions tab, then plugging in your site server, and ensure that the appropriate permissions are available. This is a great troubleshooting tool, especially for complex ACLs.
thanks for helping us to troubleshoot this issue. We double checked everything what you mention and it seems to be ok.
When you mention DNS i checked the query from the amtproxymgr.log and i found that it tries to put DC with country specific DNS suffix(which are not exist) as our DNS suffix is country specific and it is different than the DC. So i believe that there is the problem but i don't know if there is any possible solution ?
With best regards,
I'm not quite sure I understand what you're saying. Can you use specifics, or at least examples, and attach screenshots if at all possible? When you run nslookup (from the site server), and type in the FQDN for your AD domain, you should get back the IP addresses for your domain controllers. If that's not what's happening, then this could be what's causing your issue (and probably others).
sorry that i was not enough clear. Our domain is europe.<firmname>.com and our DNS suffix for the country is bg.<firmname>.com. I saw in the amtproxymgr.log that the configuration manager is trying to make a record in the AMT OU with the following line:
AD Task - CreateObject failed. FQDN: <computername>.bg.<firmname>.com, ADDN: OU=Out of Band Management Controllers,OU=Computers,OU=Staging,OU=BG,DC=bg,DC=<firmname>,DC=com, UUID: 810A5C92-554B-CB11-936B-BC56ACB66FF3, AMT Version: 4.1.3.
Failed to run instruction: ADT CREATE;<computername>.bg.<firmname>.com;OU=Out of Band Management Controllers,OU=Computers,OU=Staging,OU=BG,DC=bg,DC=<firmname>,DC=com;810A5C92-554B-CB11-936B-BC56ACB66FF3;4.1.3;891300008A899ECF00E921757615303438BB7C9E89AC04C4F0E1ECF3E5CAA46EB737A54731B03F8BC514BA561400000042000000480000000366000000000000A13EA22381536D300A0D3701B7EF7739BC9F2FA445325FE6A798BEFC9346D8B4F1A74B3C675EE75A13FAED6740CA322ADBB6D66F6BBA01472ECB5C123338651AA078E862DC6964D4675C
So here in my opinion configuration manager is trying to find Domain Controller BG, but our domain is EUROPE not BG, so i think that this is an issue.
I think that this part of instruction should look like this:
So i want to ask you if there is any possibility to fix this issue.
Thanks in advance.
With best regards
I am not sure if you are still experiencing problems creating objects within your AD OU during provisioning ?
From what I read in the thread, you have a DNS domain name that is different than your AD domain name ?
Can I make two suggestions
1. What errors appear in your Windows event logs on the Out of Band Service Point ? There are likely to be some events that give a better idea of the problem occuring here. You will likely get a better "hit" rate if you can locate those events and "google" on them
2. You may like to refer to http://support.microsoft.com/kb/258503 which talks about situations involving different DNS and AD domain names and provides some information and links to handle this type of situation
We still experiencing problems creating objects within our AD OU.
We have provisioned one new system to see what errors will appear in the logs. There was no errors with Event ID: 5788 or Event ID: 5789 in the System or the Application logs at all. The only error related to the Out of Band Service Point was with Event ID: 7602 from source SMS Server.
Log Name: Application
Source: SMS Server
Date: 15.10.2009 18:10 ч.
Event ID: 7602
Task Category: SMS_AMT_CONTROL_MANAGER
Computer: <conf. manager server>.bg.<firmname>.com
On 10/15/2009 6:10:39 PM, component SMS_AMT_PROXY_COMPONENT on computer <conf. manager server> reported: Failure: The AMT Proxy Manager failed to add a object into AD. FQDN: <comp. name>.bg.<firmname>.com, ADDN: OU=Out of Band Management Controllers,OU=Computers,OU=Staging,OU=BG,DC=bg,DC=<firmname>,DC=com, UUID: 8183ADC5-DA4A-CB11-9F50-BB37A009D047, AMT Version: 4.1.11.
Possible cause: the SMS service account does not have permission to publish the object in the Active Directory.
There was no other errors during provisioning in the Windows event logs.
We will take a look in this MS article and will let you know if this was helpfull for us.
With best regards,
From the thread, it sounds like you might have a multiple domain type setup. Do you have a 2 way transitive trust established between both domains?
How about your CA. From what you say it sounds like you set up a lab, but are having difficulty implementing it?
Seeing this error "Possible cause: the SMS service account does not have permission to publish the object in the Active Directory." at the end of your log tells me that you didn't give your Out of Band Management Point Full permissions to the OU where you want the MEBx objects created.
These are the steps that I took to configure this part of the process:
At this point, I also allowed the SCCM OOB MP Group to the Systems OU, but not quite Full Permissions. I gave it control to only the objects that it creates. This way the machine account or group doesn't have full control over every system object in the System OU.
Let me know if you need any help or clarification. I hope this helps. Good Luck!
thanks for the help. We have a disjoint namespace with the following setup "When a single Active Directory domain is split into separate DNS namespaces" from the described here.
So there is no multiple domain type setup. For the permissions we have followed the Quick Start Install Guide for SCCM SP1 Rev1.9.1, so the described from you steps are already made, but that didn't help us.
We tried and Resolution for Cause 2 - Method 2 from KB258503, but that wasn't also helpfull for us.
With best regards,
Hi Kin, can you try to shorten your AMT OU. There is a known issue in SP2 with long AMT OU path, I believe it also existed in SP1. See: http://technet.microsoft.com/en-us/library/ee619962.aspx
thanks for the support. We have tried and this, but that wasn't helpfull. In the meantime we have opened a ticket in MS, as this issue is MS related in our opinion and here what they said:
“We do not support disjoint namespaces with AMT and ConfigMgr SP1. Those types of scenarios were not tested and as we’ve now discovered, may have problems associated as well. At this time there is no support for this configuration with ConfigMgr SP2 either. However we will investigate what it would take to offer that support and make a determination at a later date”
“The answer to this problem would be to allow your clients to register in the correct DNS namespace that matches up to your AD LDAP path specified.”
So currently there is no workaround for this problem with disjoint namespaces.
Thank you to all for your cooperation.
With best regard,