top of page

OUR PRECONDITIONS

  • The old network infrastructure, referred to as OldNet:
    Doesn’t support 802.1x.
    Two domains on different VLAN’s with a one way trust, referred to as Enterprise and Educational.
    The two domains have their own network infrastructure, different IP Helpers, DNS, DHCP and so on.

  • The new infrastructure, referred to as NewNet:
    802.1x is required using CISCO ISE and Layer 3 switches.
    Only one fallback net with its own IP range, common for both domains, which also supports WebAuth guest access.
    The two domains still have their own IP range, DHCP, DNS etc. but will use the same PXE-server since PXE boot is taking place on the fallback network.

  • Both the old and the new network infrastructure will be used to deploy Windows 10 x64 and Windows 7 x86.

  • MAB will not be used during OSD, the network team don’t want to spread a special OSD VLAN so clients will get an IP address according to its current location and only certificate-based authentication is allowed.

  • The task sequence needs to support both the new computer and refresh scenario as well as BIOS to UEFI conversion regardless of the currently installed operating system.
    The scripts used for managing 802.1x needs to support Windows 7 and its PowerShell version.

Search
Writer's picturesomeguy100
Jun 19, 20201 min read

MDM Comanagement detected as Coexistent

Short blog post. Recently we've tried to enroll our hybird-joined computers to Intune. We started to get calls about users experiencing errors while trying to install updates. All of the computers that were affected were still at Win10 1709.

The ConfigMgr agent somehow believes that there's a 3rd party MDM managing the computer.

CoManagementHandler.log:

<![LOG[This device is enrolled to an unexpected vendor, it will be set in co-existence mode.]LOG]!><time="09:03:15.662-120" date="06-09-2020" component="CoManagementHandler" context="" type="2" thread="10964" file="MdmRegLib.cpp:476">
<![LOG[Current workloads should be set to co-existence]LOG]!><time="09:03:15.662-120" date="06-09-2020" component="CoManagementHandler" context="" type="1" thread="10964" file="CcmUtilLib.cpp:2925">
<![LOG[Workload settings is different with CCM registry. Current value is 4294967295, expected value is 1]LOG]!><time="09:03:15.688-120" date="06-09-2020" component="CoManagementHandler" context="" type="2" thread="10964" file="CcmUtilLib.cpp:3033">

We're not uploading recovery keys for bitlocker or anything like that at the moment so please keep that in mind before trying what I am about to write. The solution seems to be to delete all registry keys under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Enrollments but two. Since SYSTEM only have read access to both of those keys just run this command:

"Reg delete HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Enrollments /f"


To run a program (of a package) didn't work for us so we needed to execute it on the affected clients using "Run script". And since 1709 doesn't support device enrollment we needed to wait for the computer to restart and for a user to login before the enrollment succeeded.

514 views0 comments

Comentarios

bottom of page