Thursday, June 16, 2016

ConfigMgr issues and improvements posted on Microsoft Connect (part 2)

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 :-)

No comments:

Post a Comment