Hi,

we are facing strange issue within Intune, when manually deleted SCEP User certificate is not re-enrolled automatically based on configuration profile. Also this configuration profile is NOT marked as non-compliant even after a week of syncs for that device. And what is the most important, SCEP configuration profile definition from point of view of macOS knows, that SCEP certificate is missing because, when you open config profile within Settings/Device Management on macOS, there is error saying “Not found in keychain”.

Documentation https://learn.microsoft.com/en-us/mem/intune/protect/remove-certificates saying exactly following:

Manual deletion of a certificate is a scenario that applies across platforms and certificates provisioned by SCEP or PKCS certificate profiles. For example, a user might delete a certificate from a device, when the device remains targeted by a certificate policy.

In this scenario, after the certificate is deleted, the next time the device checks in with Intune it’s found to be out of compliance as it is missing the expected certificate. Intune then issues a new certificate to restore the device to compliance. No other action is needed to restore the certificate.

So it means that if user delete SCEP User certificate from keychain, doesn’t matter if it was intention or accident, as long as I keep SCEP Configuration profile within Intune for exact device and user, Intune must initiate re-enrolling/re-generating new certificate based on this profile.

This is not happening on our macOS’s laptops and only workaround I’ve got from MS Support is to remove device from Configuration profile and then return it back… But imagine when you have 1000 macOS laptops and 100 users (extreme example, but could happen, i.e. developers trying things) delete their certificates from Keychain. Whole action to removing devices and users from that profile is time wasting. first create special groups to include affected devices and affected users, then add that group to exclusion, wait a long for sync of all macOS’s, then starting to removing those devices and users from group to return configuration profile back.

Also comment from MS Support was, that they cannot escalate the case to different team, because I have selected exact time zone and only they are responsible for that time zone (what a bullshit???) and that my case is already escalated withing his team manager. But his team manager is same low-skilled incompetent as engineer got my support case. And if certificate is returned when I remove and re-add config profile, then case is finished (what another bullshit????) – but from my point of view it’s not finished because it’s not a fix, it’s workaround and very complex, time and money wasting workaround.

Note to Microsoft: STOP hiring !!!! low-skilled incompetent Indian support teams, just because they costs less then European or United States engineers!!!! You are wasting our money, our time, our patience and you want more and more money for your subscriptions and we are getting less and worst services.

​Hi, we are facing strange issue within Intune, when manually deleted SCEP User certificate is not re-enrolled automatically based on configuration profile. Also this configuration profile is NOT marked as non-compliant even after a week of syncs for that device. And what is the most important, SCEP configuration profile definition from point of view of macOS knows, that SCEP certificate is missing because, when you open config profile within Settings/Device Management on macOS, there is error saying “Not found in keychain”. Documentation https://learn.microsoft.com/en-us/mem/intune/protect/remove-certificates saying exactly following:Manually deleted certificatesManual deletion of a certificate is a scenario that applies across platforms and certificates provisioned by SCEP or PKCS certificate profiles. For example, a user might delete a certificate from a device, when the device remains targeted by a certificate policy.In this scenario, after the certificate is deleted, the next time the device checks in with Intune it’s found to be out of compliance as it is missing the expected certificate. Intune then issues a new certificate to restore the device to compliance. No other action is needed to restore the certificate. So it means that if user delete SCEP User certificate from keychain, doesn’t matter if it was intention or accident, as long as I keep SCEP Configuration profile within Intune for exact device and user, Intune must initiate re-enrolling/re-generating new certificate based on this profile. This is not happening on our macOS’s laptops and only workaround I’ve got from MS Support is to remove device from Configuration profile and then return it back… But imagine when you have 1000 macOS laptops and 100 users (extreme example, but could happen, i.e. developers trying things) delete their certificates from Keychain. Whole action to removing devices and users from that profile is time wasting. first create special groups to include affected devices and affected users, then add that group to exclusion, wait a long for sync of all macOS’s, then starting to removing those devices and users from group to return configuration profile back.Also comment from MS Support was, that they cannot escalate the case to different team, because I have selected exact time zone and only they are responsible for that time zone (what a bullshit???) and that my case is already escalated withing his team manager. But his team manager is same low-skilled incompetent as engineer got my support case. And if certificate is returned when I remove and re-add config profile, then case is finished (what another bullshit????) – but from my point of view it’s not finished because it’s not a fix, it’s workaround and very complex, time and money wasting workaround. Note to Microsoft: STOP hiring !!!! low-skilled incompetent Indian support teams, just because they costs less then European or United States engineers!!!! You are wasting our money, our time, our patience and you want more and more money for your subscriptions and we are getting less and worst services.  Read More

​