Senthilkumar Pandurangan

Support Escalation Engineer | Microsoft Intune

Disclaimer: This posting is provided "AS IS" with no warranties and confers no rights

1. Find the policy from the list ADMX-backed policies.
2. Find the Group Policy related information from the MDM policy description.
3. Use the Group Policy Editor to determine whether there are parameters necessary to enable the policy.
4. Locate the Policy Definition file (C:\windows\PolicyDefinitions) and open with any XML Editor.
5. Create OMA-URI and its value for the policy.
6. Create a Device Configuration Policy in Intune and Assign to the user.

• GP English name: Approved Installation Sites for ActiveX Controls
• GP name: ApprovedActiveXInstallSites
• GP path: Windows Components/ActiveX Installer Service
• GP ADMX file name: ActiveXInstallService.admx

1. Open Run-> GPEDIT.MSC
2. Use GP path identified from Step 1 and navigate to Windows Components/ActiveX Installer Service

• Class defines whether it is Device policy or User policy.
• Elements defines how the value should be formatted.

Today's blog post is about the steps required to "Install Dynamics CRM for Outlook without an Internet connection using ConfigMgr".

[NOTE: CRM 2016 for Outlook, Office 2016, Windows 10-x64 Client and ConfigMgr 2012 R2 SP1(CU2) are the versions used while creating this document.]

1.     Download Microsoft Dynamics CRM 2016 Client for Outlook from Microsoft Download center.

           https://www.microsoft.com/en-US/download/details.aspx?id=50370

2.     Download both x86 and x64 versions.

3.     Create two folders for each version like below.

4.     Extract both files in two different folders.

5.     Create the below folders with the exact name in both x86 and x64

dotNETFX

ReportViewer

SQLCE

SQLExpr

SQLExprRequiredSp

VCRedist

VCRedist10

WindowsIdentityFoundation

SQLSystemCLRTypes

6.      Download the Prerequisite files corresponding to each folders you created above.

dotNETFX

Microsoft .NET Framework 4 (Offline Installer (64 and 32-bit)) - NDP452-KB2901907-x86-x64-AllOS-ENU.exe

ReportViewer

Microsoft Report Viewer 2012 Runtime - ReportViewer.msi

SQLCE
Microsoft SQL Server Compact 4.0 SP1 (64-bit) - SSCERuntime_x64-ENU.exe

Microsoft SQL Server Compact 4.0 SP1 (32-bit) - SSCERuntime_x86-ENU.exe

SQLExpr
SQL Express 2012 Express SP2 x86 (32-bit, used by both 64 and 32-bit versions of Dynamics CRM for Outlook) - SQLEXPR_x86_ENU.exe

 SQLExprRequiredSp
SQL Express 2008 R2 SP3 - SQLEXPR_x86_ENU.exe

VCRedist
Microsoft Visual C++ 2013 Redistributable (64-bit) - 12.0.21005 - vcredist_x64.exe
Microsoft Visual C++ 2013 Redistributable (32-bit) - 12.0.21005 - vcredist_x86.exe

VCRedist10
Microsoft Visual C++ Redistributable SP 1 (64-bit) - 10.0.40219 - vcredist_x64.exe

Microsoft Visual C++ Redistributable SP 1 (32-bit) - 10.0.40219 - vcredist_x86.exe

WindowsIdentityFoundation
Windows Identity Foundation, Windows 7 (64-bit) - 6.1.7600.0 - Windows6.1-KB974405-x64.msu

Windows Identity Foundation, Windows 7 (32-bit) - 6.1.7600.0 - Windows6.1-KB974405-x86.msu

SQLSysClrTypes.msi
SQLSysClrTypes.msi (32-bit) - SQLSysClrTypes
SQLSysClrTypes.msi (64-bit) - SQLSysClrTypes

(Important: After downloading the file, you must rename it according to the bitness of the client. Rename SQLSysClrTypes.msi to: SQLSysClrTypes_x86.msi for the 32-bit client; SQLSysClrTypes_x64.msi for the 64-bit client.)

7.     After downloading all the files, the folder structure will look like below for each x86 and x64 version of CRM 2016 Client.

8.     Create two Custom Global Condition to confirm the Outlook version installed on the machine. This will be used as a requirement in the Application Deployment Types.

9.     Create an Application in ConfigMgr.

10.   Add a deployment type for x64 - CRM2016 Client installation to the Application.

11.   Deployment Type Properties may look like below for x64-Install-CRM2016Outlook

Command line used above : SetupClient.exe /Q /l "%SYSTEMDRIVE%\Temp\CRM_2015_Install.log"

Used MSI Product Code for detection. {0C524D20-1409-0080-8A9E-0C4C490E4E54}

Used the above created Global Condition x64-Outlook-Office16 for x64 Deployment Type as requirement.

 12.  Deployment Type Properties may look like below for x86-Install-CRM2016Outlook

Command line used above : SetupClient.exe /Q /l "%SYSTEMDRIVE%\Temp\CRM_2015_Install.log"

Used MSIProduct Code for detection. {0C524D20-1409-0080-8A9E-0C4C490E4E54}

Used the above created Global Condition x86-Outlook-Office16 for x86 Deployment Type as requirement.

13.   After creating the application Distribute the content to the Distribution Points and make sure the Content Distribution Progress shows as "Installed" and deploy the application to a client machine.

14.   Once the client installed the CRM for Outlook Successfully, it will have the Installation Logs under "%SYSTEMDRIVE%\Temp" as below.

15.   In case of failures, you can refer the CRM_2015_Install.log for errors.

Senthilkumar Pandurangan

Support Escalation Engineer | Microsoft System Center Configuration Manager

Disclaimer: This posting is provided "AS IS" with no warranties and confers no rights

For upgrading the existing clients to Windows 10, it supports "In-Place upgrade" with the task sequence which can be imported from the blog post from Aaron Czechowski, Senior Program Manager, Enterprise Client and Mobility.

Today we are going to Build and Capture a Windows 10 Image using the ConfigMgr 2012 R2 SP1 Task Sequence with Build-In Apps removed from Reference Image.

Windows 10 comes with some built-in apps, like Mail, Calendar, OneNote (Touch), 3D Builder, etc. Sometimes, Enterprises doesn't want to have these apps deployed to all users as part of the Imaging.

We can remove the Built-In apps from Windows 10 while capturing the reference Image. These apps are provisioned with the Operating System Image and will be installed for each user when they login.

Even if we remove the apps from a reference machine by right click and uninstall them, it is uninstalled only for that User Profile. So when a next user logs-in it will be installed for that user.

How to avoid this? Here is the procedure.

1. Download the attached RemoveApps.txt.

2. Edit the file using Notepad and modify the first line with the apps which you don’t want to keep in your Image.

3. You can get the names for each Application by running the below PowerShell script on a Windows 10 Device. (Requires Elevated permissions)

Get-AppxProvisionedPackage -online | select PackageName

NOTE: All Apps doesn't support removal. So make sure you are removing an App which can be installed back from Windows Store.

4. Once modified the file Save it as "RemoveApps.ps1"

5. Create a Package named "RemoveApps" which contains the above modified PowerShell script as Source. This doesn't require any program.

6. Create a Simple ConfigMgr Task Sequence to Build and Capture Windows 10 Image.

7. Modify the Task Sequence and add a group named like "Remove Built-In Apps" after "Setup Windows and ConfigMgr" step in the Task Sequence.

8. In the Group add "Run Command Line step" to set the PowerShell Execution policy and name like "PS Execution Policy".

powershell.exe -Command {Set-ExecutionPolicy Unrestricted}

9. Next to that add another step to "Run PowerShell Script" and name it like "RemoveApps"

10. Configure the options as below.

11. Deploy the Task Sequence to a client which you are going to use for Build and Capture Windows 10.

12. Use the captured Image for imaging new clients. 

Senthilkumar Pandurangan

Support Escalation Engineer | Microsoft System Center Configuration Manager

Disclaimer: This posting is provided "AS IS" with no warranties and confers no rights

RemoveApps.txt

• HTTPS Management Points in a Site.

• Same Active Directory Forest

• HTTP Managements

There is no control to let client machines communicate to a specific Management Point. Also multiple Management points were available for Fault Tolerance and could not be used Load Balancing.

Kind of not useful right? Yes. Now that's changed.

After lot of requests from customers around the globe, now a new feature has been added in SP2 / R2SP1, to assign Management Points to a Boundary group.

You can find more details about the feature documented in TechNet below.

https://technet.microsoft.com/en-us/ec3bae17-9b97-42d0-9c23-f634a3665606#BKMK_PreferredMP

To make the clients to choose their Preferred Management Points assigned to their respective boundary groups, you must configure the option below in Hierarchy Settings.

“In the Configuration Manager console, click Administration > Site Configuration > Sites > Hierarchy Settings. Then, on the General tab of the Hierarchy Settings, select Clients prefer to use management points specified in boundary groups.”

Hold on. Here is the catch. Whatever information provided above is applicable for the Assigned Sites which is Primary Sites.

Then what about secondary sites?

For Secondary Sites, the Assigned Site is always its Parent Primary Site. Then how it affects the Secondary Site clients?

Let us see with an example scenario.

Hierarchy:

=========

Central Admin Site: CAS

Primary Site: PR1

Site Server: Primary.contoso.com

Management Point: Primary.contoso.com, MP01.contoso.com 

Boundary Group 01 – with Primary.contoso.com

Boundary Group 02 – With MP01.contoso.com

Client 01 – Falls under Boundary Group 01

Client 02 – Falls under Boundary Group 02

Secondary Site: S01

Site Server & Management Point & DP: Secondary.contoso.com

Sec-BoundaryGroup 01 – with Secondary.contoso.com as MP and DP

Sec-BoundaryGroup02 – No MPs added (We have a DP added for Content Location)

Client 03 – Falls in Sec-BoundaryGroup 01

Client 04 - Falls in Sec-BoundaryGroup 02

Hierarchy setting: “Clients prefer to use management points specified in boundary groups” is selected.

With the above configured hierarchy, here's what the result would look like:

Client 01 Selects the Primary.contoso.com MP for communications.

Client 02 Selects the MP01.contoso.com for communications.

Client 03 Selects the Secondry.contoso.com for communications.

Client 04 Selects Primary.contoso.com (Assigned MP) for communications.

Client 04 is in Secondary Site boundary and how can it communicates with Primary MP. Correct. It should not. As per TechNet, the Preferred MP configuration in Boundary Group and the Hierarchy Setting “Clients prefer to use management points specified in boundary groups” affect the Assigned Site.

Here is the conclusion:

Irrespective of the option “Clients prefer to use management points specified in boundary groups” is selected or not selected, If the hierarchy contains a Secondary Site with multiple Boundary Groups associated with it for site assignment, each Boundary Group “MUST” have the Management Point of that Secondary Site is added.

A concern might arise here. In a secondary Site, we cannot have more than one MP and it can only be installed on the Site Server. We also have the DP role installed during the Site Installation.

So as per the above conclusion, if we add the Secondary MP (DP too) to multiple boundary groups assigned to a Secondary Site and when the client (Client 04 from above example) sends a content location request (Packages or Applications or Updates), it will receive the Location of both MP (DP ) and Local DPs added to the Boundary Group.

So when we add the Secondary Site MP to the remote Boundary Groups, mark it as “Slow” and the clients will see them as “Remote”. Until a specific deployment allows clients to download content from “Slow” Distribution Points, the clients wouldn't download the content from the DP marked as Remote.

Senthilkumar Pandurangan

Support Escalation Engineer | Microsoft System Center Configuration Manager

Disclaimer: This posting is provided "AS IS" with no warranties and confers no rights

Here is an interesting issue I worked with Umair Khan on a support case. This will help in analyzing collection evaluation in a hierarchy for user collections and system collections.

Issue:

=====

Only a single custom user collection (rest others work fine) doesn’t replicate it members up in the hierarchy to CAS. We see 10 members in that collection in primary site and nothing in CAS. We have a CAS and multple primaries and all these 10 members we are talking belong to a single primary.

More details on how the collection is defined. It’s an Application collection meant for uninstallation applications. So it detects the application is installed for a machine by a user by the SMS_G_System_AppClientState class. The query used is as described in

https://blogs.technet.com/b/configmgrdogs/archive/2014/11/03/managing-app-v-deployments-in-configmgr-2012.aspx

//

select SMS_R_USER.ResourceID,SMS_R_USER.ResourceType,SMS_R_USER.Name,SMS_R_USER.UniqueUserName,SMS_R_USER.WindowsNTDomain
from SMS_R_User inner join SMS_G_System_AppClientState on SMS_R_USER.UniqueUserName = SMS_G_System_AppClientState.UserName
where SMS_G_System_AppClientState.AppName = "APPLICATIONNAME"
and SMS_G_System_AppClientState.ComplianceState = 1

//

Assessment:

=========

Now the basic things that initially comes to mind when the data is there on the child but not there on the CAS is replication. Yes, DRS! But we have verified the change tracking number and changes for the replication group Collection_Membership being the latest on CAS and links are ACTIVE.

VLOGS doesn’t show any exceptions in processing any record and all looks good. So why the mismatch?? Or What’s happening here?

Dissection:

========

Here basically will defy and frustrate you unless the evaluation logic is known. I will first explain the concept then we will come back to the issue again.

Suppose we have a hierarchy:

Difference between evaluation in a User collection and Device collection:

So collections ([Collections]) are global data, no matter you create them at any site they will replicate to all other sites. [CollectionMembers] as client data are site data. So if I create a collection membership rule for a device collection as all Windows 7 machines on CAS, what happens?

•  Note that there is no CollEval at CAS, and the rule flows down to each primary as global data. The collection membership is locally calculated for each site individually and independently. And once done each sites updates its [CollectionMembers] and send the membership to CAS.
• Now CAS then holds the data in the [CollectionMembers] from all the sites.

So suppose if there were total 7000 Win7 machines in the hierarchy. What we will see on CAS is Member Count = 7000 and Members Visible on site = 7000. Taking the example of hierarchy above supposedly assuming if each primary has 3500 Win7 clients then on both the Primary sites collection view will show Member Count = 7000 and Members Visible on site = 3500.

Yes, the primary knows the total count as it is again a global data stored in [CollectionMemberCounts]

I hope majority of us know the part above. Let’s bring in the tricky part. Is it the same for a user collection in a hierarchy? You guessed it right NO!

Now the reason for that NO is we don’t have the need for each site to independently send the data to CAS as USERS are considered as global data. So what do we do?

[Thanks to Jonathan Shi for this vital piece of Info that actually helped in cracking the case]

Everything thing is same except the part I already mentioned. We just select a single site to send the membership changes to the CAS on behalf of all other primaries. So that special primary is the first primary site that you created in the hierarchy.

So if the previous admin left the job, how do we find the first primary site?

//

select * from sites where ReplicatesReservedRanges = 1

//

Yes, the above will give you the first primary site. Coming back to the assumed hierarchy, if I have a user collection and I added a user resource in PR2 then:

1. PR2 on collection evaluation will update its CollectionMembers. So the Member Count on PR2 will be still the old value but ‘Members Visible on Site’ will increase by 1 as mentioned earlier CollectionMemberCounts is global data and CAS still does not know of this addition.

2. PR1 on collection evaluation will update its CollectionMembers and *send the changes to the CAS*. The Member Count on PR1 will be still the old value but ‘Members Visible on Site’ will increase by 1 as mentioned earlier CollectionMemberCounts is global data and CAS still does not know of this addition.

3. CAS will see now a member’s addition via DRS message received and update its members and update the total member count for that collection.

4. This will replicate back to the Primary site and then member count will be updated on them.

So as of now I think in logical means be it User or Device collection the Members visible on site cannot be greater than total Member Count. We are done with the concept part now! J

Coming back to the issue, why are CollectionMembers not replicating up to CAS on this scenario.

Note that we use SMS_G_System_AppClientState class in the collection query. This actually corresponds to fn_ListAppClientState() function in SQL. If you see its definition:

//

SELECT 

         appname.DisplayName AS AppName,

         ci.CI_ID as AppCI,

         ci.ModelId as AppModelID,

         ci.ModelName as AppModelName,

         sd.Name0 as MachineName,

         us.FullName as UserName,

         ccs.ComplianceState as ComplianceState,

         ccs.CIVersion as Revision,

         sd.ItemKey as ResourceID

  FROM CI_CurrentComplianceStatus ccs

  INNER JOIN vSMS_ConfigurationItems ci ON ci.ModelId = ccs.ModelID AND ci.IsLatest=1 AND ci.CIType_ID = 10

  INNER JOIN System_DISC sd ON sd.ItemKey = ccs.ItemKey 

  INNER JOIN Users us ON us.UserID = ccs.UserID

  LEFT JOIN fn_LocalizedCIProperties(@LocaleID) AS appname ON ci.CI_ID = appname.CI_ID

//

• So this function is basically telling you the compliance state for an application installed on a machine by a user.

• So here is the catch, CI_CurrentComplianceStatus is a site data table and though user is global info, machine is site data. We will replicate the whole site data up in the CAS.

• Also, take an example of the hierarchy here, if suppose a user installed an app in PR2 then:

1. PR2 collection membership will update and it will update the CollectionMembers locally.

2. PR1 on its evaluation of this collection *will not find any changes* as the CI_CurrentComplianceStatus table is site data specific. And hence PR2 data will stay at PR2 and then move to CAS but not known to PR1.

3. Now, Since PR1 is the first site it will not replicate the CollectionMembers as it did not know of the changes of insertion in the PR2 CollectionMembers as collection was based on CI_CurrentComplianceStatus which is site data specific.

4. CAS will not know of any members being added and will also not update its CollectionMembers and increase the CollectionMemberCounts.

Yes, that’s the issue :)

To summarize how it looks when we have the issue. SQL queries:

On PR2: [Members visible on site > Member count]

Console

SQL

On PR1:

Console

SQL

On CAS:

Console

SQL

Conclusion: Don’t use a site data dependent criterion in a User based collection. Not that I can find any documentation on this and this is going by design! :)

Senthilkumar Pandurangan & Umair Khan

Support Escalation Engineers | Microsoft System Center Configuration Manager.

Disclaimer: This posting is provided "AS IS" with no warranties and confers no rights

Today we are going to see about the relation between Collection Evaluation and TempDb in SQL. Before we proceed I would like you to have a look at my previous blog to understand the various types of Collection Evaluations in ConfigMgr 2012.

Hope you are done reading my previous post. Let’s move on.

When a collection in ConfigMgr runs an evaluation, it uses the TempDb to create some temporary tables to process to insert the data based on what query we are using in Collection Rules. When I say Query, there are two types. WQL (WMI Query Language) and SQL (Structured Query Language).

In ConfigMgr we use the above two types. WQL is used by SMS Provider and SQL for Microsoft SQL Server.

Here is an example of a WQL and its equivalent SQL query for a Test collection created in ConfigMgr 2012 R2 to return all active clients.

WQL: select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System where SMS_R_System.Active = "1"

SQL:  select all SMS_R_SYSTEM.ItemKey,SMS_R_SYSTEM.DiscArchKey,SMS_R_SYSTEM.Name0,SMS_R_SYSTEM.SMS_Unique_Identifier0,SMS_R_SYSTEM.Resource_Domain_OR_Workgr0,SMS_R_SYSTEM.Client0 from vSMS_R_System AS SMS_R_System  where SMS_R_System.Active0 = N'1'

Above two statements looks similar. But they are not. You cannot run the WQL query in from SQL Management Studio. But you can execute the SQL statement.

You can see the WQL and SQL equivalent queries for any collection in SQL by running the below query. (Note: Don’t modify anything directly to table in SQL. This will impact the AdminUI functionality) Replace ‘P0000012’ with your collection ID.

select * from Collection_Rules_SQL Where CollectionID in (select CollectionID from Collections where SiteID = 'P0000012')

When will the TempDb size grow and what is the impact with Collection Evaluation?

There are certain components in ConfigMgr uses TempDb. The important one is Collection Evaluator. Collection Evaluator is Single Threaded and run one collection evaluation at a time. The reason for this is that the next collection in the Evaluation Graph may be directly or indirectly depend on the collection getting evaluated.

By Default, the TempDb size is configured as below. But SQL Administrators, may have changed based on their required settings.

If we are using an Expensive query in a Collection with lot of joins and complex where clauses, it may start filling up the TempDb.

We are most likely to use “LIKE” and “NOT LIKE” statements in Collections to get our desired objects in the collection. According to the MSDN article “NOT LIKE” statements are Expensive and avoid this to improve SQL performance.

You can run the below Statement in SQL to identify what are all the collections in your environment really has “LIKE” and “NOT LIKE” in the queries.

select SiteID, CollectionName from Collections where CollectionID in (select CollectionID from Collection_Rules_SQL where SQL like '%Like%' or SQL like '%NOT LIKE%')

 You will not see big Impact when you manage small number of systems with less number of collections. That’s why the collection query may work in your Test environment and may not give the expected result in Production environment.

When the Site is growing bigger and bigger, we will get lot of Data from clients and that puts lot of pressure in SQL.

Senthilkumar Pandurangan

Support Escalation Engineer | Microsoft System Center Configuration Manager.

Disclaimer: This posting is provided "AS IS" with no warranties and confers no rights

As we know in ConfigMgr 2007, the collection evaluation happens in all the Sites including Central Primary and All Child Primaries.

But in ConfigMgr 2012, we don't have Collection Evaluator thread in Central Administration site. Instead the evaluation happens on all the Primary Sites.

Coming to the evaluation schedule. There are three types of schedule.

Primary Evaluation:

Primary Evaluation stands for Full Collection update which runs based on schedule. There are eight default collections in ConfigMgr 2012.

The above collections are not configurable and it will be root for all collections directly or indirectly we create in ConfigMgr.

In 2007, Limiting Collections are optional. However in ConfigMgr 2012, we cannot create any collection without having a Limiting Collection.

The above collections are not configurable and all options in these collections will be greyed out. But how the collection update happens.

By default All Systems and All Users and groups collections are scheduled to do Full Evaluation Every day 4:00 AM and Enabled with Incremental Collection Evaluation.

Primary Evaluator prepares a Graph with all its Dependent collections for evaluation. For preparing the Graph it uses the below SQL statement to get the number of collections to be evaluated.

SELECT ImmediateSourceCollectionID, DependentCollectionID FROM vCollectionDependencyChain WHERE SourceCollectionID = N'SMS00001' ORDER BY [Level] ASC

Since ConfigMgr 2012, all the collections should be dependent on All Systems or All users and Groups directly or indirectly, each collection in ConfigMgr hierarchy will be doing a Full collection Evaluation at 4:00 AM Every Day, if there is any change in these Root Collection.

Express Evaluation:

Express Evaluation stands for Incremental Collection Update. This is also based on schedule. This is a Site wide option and is configurable. Default value is every 10 mins. You can change this option from ConfigMgr console.

Administration -> Site Configuration -> Sites -> Primary Site -> Configure Site Components -> Collection Membership Evaluation.

Like Full collection update, this also prepares a graph of all dependent collections and triggers update if there is any change in the depending collection (parent).

One thing we need to consider while enabling the Incremental Evaluation. It is not mandatory to enable Incremental Evaluation on all the collections. If the number of collections on the site is more and all collections are running Incremental Evaluation, the number of evaluations per day will be high and it may reduce the performance of the Site and SQL.
For example, consider a Site with 1000 collections and all are enabled with Incremental Evaluation runs every 10 Mins. It will be ((24*60)/10) *(1000) = 144000 Collection Evaluations Per day, which is way higher and reduce the performance.

Another thing we need to remember while configuring collection is,  if the Parent Collection is not enabled with Incremental Evaluation and a child collection is enabled, we will not get the desired object in the collection until the parent collection completes full evaluation or manual update. So plan accordingly.

Manual Collection Update: 

This will be triggered when we click Update Membership on a collection. Manual update happens in two different types. Auxilary Evaluation and Single Evaluation.
 
Auxiliary Evaluation runs when we trigger a manual collection update on a collection which has dependent collections. Like Full collection update, this also prepares a graph of all dependent collections and triggers update if there is any change in the depending collection (parent).
 
Single Evaluation runs when we trigger manual update on a collection which doesn't have any dependent collections. 

Hope this helps.

Senthilkumar Pandurangan

Support Escalation Engineer | Microsoft System Center Configuration Manager

Disclaimer: This posting is provided "AS IS" with no warranties and confers no rights

When a Windows 8.1 machine is Domain Joined or in work group and Installed with ConfigMgr client for system management, you cannot manage this machine using any other MDM solutions.

When I try to understand how it is restricted, I found that ConfigMgr Client installation sets a Registry value as below.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\MDMPolicy
Name : ExternallyManaged
Type : REG_DWORD
Value : 1

The reason for this is to avoid managing the same device using multiple management solutions. It is not required to manage the same machine using multiple solutions.

This is by design. Hope this helps.

Senthilkumar Pandurangan

Support Escalation Engineer | Microsoft System Center Configuration Manager

Disclaimer: This posting is provided "AS IS" with no warranties and confers no rights