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
Recently it was needed to install ConfigMgr Current Branch (1602) in an environment with multiple forests with a single domain each. Most of times I install ConfigMgr in a single forest, where one or multiple domains resides or multiple forests with a trust in between. This time it was needed to publish site information across multiple forests without any trusts. Let's have a look at the steps taken.
First you need to configure conditional forwarders from the forest where ConfigMgr is installed to all remote forests where site systems are needed. Otherwise no forest discovery is possible at all.
After that the following must be done:
-Add a forest in ConfigMgr with a domain account from the remote forest. This account must have read permissions on the root of the forest at minimum.
-Run a schema update on the remote forest (schema master) manually by copying the files needed.
-Create a System Management container on the remote forest (without additional permissions needed)
-Create a boundary and boundary group for the remote forest (may be created by forest discovery automatically)
-Create a Network Access (NA) account on the remote forest and configure it in the ConfigMgr console
-Create a Push Installation (PI) account on the remote forest and configure it in the ConfigMgr console
-Run system discovery on the remote forest (with the remote NA account), where LDAP locations must be configured manually
-Set publishing in Site properties on the remote forest
After that forest discovery and publishing must be succeeded. When installing remote site systems, make sure the account for the remote forest is used now. This because the ConfigMgr computer account cannot be used in this case. Hope it helps!
Today (June 21th) the latest ConfigMgr (preview) version is released: Update 1606 for ConfigMgr Technical Preview. Update 1606 for Technical Preview is available directly in the ConfigMgr console. If you want to install ConfigMgr Technical Preview for the first time, the installation bits (currently based on Technical Preview 1603) are available on TechNet Evaluation Center.
This update includes the following improvements:
-ConfigMgr as a managed installer with Device Guard (ConfigMgr-deployed software is automatically trusted)
-Cloud Proxy Service (manage ConfigMgr clients on the Internet, with an Azure subscription)
-Grace period for application and software update deployments (give users a grace period to install required applications or software updates)
-Multiple device management points for Windows 10 Anniversary Edition devices (automatically configures an enrolled device to have more than one device management point available for use)
This update also includes new features for customers using ConfigMgr integrated with Intune (hybrid scenario):
-Device categories (automatically place devices in device collections when used in hybrid environments)
Hope that nested task sequences will be available soon too!
Just great a new (preview) version is available now!
Source: Enterprise Mobility and Security Blog
Recently I did some blogposts about ConfigMgr issues and improvements, which I posted on Microsoft Connect.
More about that here:
Issue in ConfigMgr Current Branch (1602) with Intune subscription Some small bugs found in ConfigMgr Current Branch (1602)
The current status after two months looks good to me:
-Issue in ConfigMgr Current Branch (1602) with Intune subscription (when changing tentant) = Fixed
-Order in ConfigMgr and SCEP policies not corrected after removing other policies = By design
-Remote configuration failed on WSUS Server, after ConfigMgr Current Branch upgrade = Active
-The SMS Provider reported an error, Quota violation, when drivers are movged to a different folder = Fixed
-To enable use the Add Site System Roles wizard to add the Intune Connector role = Fixed
-This device might have Activation Lock enabled and might require the user's Apple id and password to be entered to be reactivated = Won't fix
-Default layout for deployment status of task sequences (Monitoring part) = Active
-To identify the Windows Store link for this application, browse to a computer that has the application installed = Active
As for the "Order in ConfigMgr and SCEP policies not corrected after removing other policies" the following details:
This is actually changed by design in ConfigMgr v1511. Several customers asked for the ability to configure security scopes for antimalware policies; there are some existing Connect items for it (e.g. 1015855 and 1015641).
The reason we made this change is because a ConfigMgr admin who is subject to security scopes cannot always "see" the policies of other users. If they change the priorities of their own policies, when the Console cannot "see" the other admins' policies, then it is possible to end up with two policies having the same priority. If both of these policies are present on a client, then the client cannot reconcile the two policies and may encounter errors.
We altered the priority logic to guarantee that no two have the same priority, even when there are scoped users involved. As a result of this we no longer reshuffle priorities when policies get deleted.
Very good to see that Microsoft is still making progress here, with most issues fixed and a few active! Way to go :-)
Recently (May 27, 2016) for ConfigMgr Current Branch (1602) is released, also known as KB3155482. It fixes multiple issues on both ConfigMgr and Microsoft Intune. It cannot be downloaded, but will be available in the ConfigMgr console instead.
Here's a list of issues that are fixed:
-Remote Control (1x)
-Site Systems (1x)
-Microsoft Intune and mobile device management (5x)
As you can see it fixes mostly Intune (MDM) parts. When not using Intune, just wait for build 1606 coming soon.
This hotfix is available for installation in the Updates and Servicing node of the ConfigMgr console. If the service connection point is in offline mode, you have to re-import the update so that it is listed in the ConfigMgr console.
For more information on the update have a look here:
Microsoft Support
Hopefully the ConfigMgr certificate issue is solved now too!
Last year we began moving Intune Account Portal functionality to the Office 365 management portal. This move is now complete (May 26, 2016) and the Intune Account Portal has been retired.
Users and Groups are managed in appropriately named tabs whereas purchasing and subscription management is now under Billing.
Depending on how you purchased, you will access software downloads at either the Volume Licensing portal or the Microsoft Online Services Customer Portal.
Be sure to update your bookmarks.
Read more about the move in our Microsoft Intune blog or go directly to the new Office 365 management portal with your existing credentials.
Source: Microsoft Blogs
Within ConfigMgr Current Branch (1602) the production client isn't updated by default anymore. After installation (and/or upgrade) both a ConfigMgr Client Package and ConfigMgr Client Piloting Package are created. This is different in earlier versions, where the production client was upgraded immediately. Benefit of this is to test the client first, before enroll it to all company devices.
Both a ConfigMgr Manager Client Package and ConfigMgr Manager Client Piloting Package are available now.
During upgrade a pre-production collection must be created. Just add a few systems in it for testing purpose, and you will be fine.
Within a deployment task sequence this can be tested to. Just deploy a system with the new pre-production client, and check if it's installing fine. Just choose "Use pre-production client package when available" and browse to the ConfigMgr Client Piloting Package.
When successful go to Cloud Services > Updates and Servicing > and check Client Update options. Check "I am ready to make pre-production client version available to production" to update the Configuration Manager Client Package. The ccmsetup.exe in the ConfigMgr client folder will be upgraded now. Yeah!
Just great to have more control on the client version now!
