Kolldhee's Blogs https://docs.microsoft.com/archive/blogs/kolldhee/feed.xml Wed, 17 Apr 2019 03:42:55 GMT en-US hourly 1 Intune Managed mobile devices fail to list the apps deployed to security groups synched from on-premise https://docs.microsoft.com/archive/blogs/kolldhee/intune-managed-mobile-devices-fail-to-list-the-apps-deployed-to-security-groups-synched-from-on-premise Mon, 17 Oct 2016 12:49:52 GMT https://blogs.msdn.microsoft.com/kolldhee/?p=275 SCENARIO: In the Intune portal, groups have been created with multiple levels of nesting. User membership criteria has also been configured for the nested groups. However, the users do not get the Intune managed applications on their portal even though they have been assigned.   RE-PRO AND TROUBLESHOOTING: To validate if this is a tenant-specific issue, I went ahead and setup a test scenario in my lab tenant and I could quickly reproduce the same problem as the customer.  As can be seen in the screen snippet below, the Parent group is named “Security Group" with two nested groups - Group A and Group B . In-built LOB applications are deployed to the nested groups and none of the devices were receiving any of the deployed apps on the company portal. At this point, we should already have our security groups reflecting on the office 365 and Azure portals. We checked the Azure AD sync(AADSync) environment and we could confirm that the nested groups are already linked with the necessary on-premise groups. But for some reason not known yet, the desired applications do not get listed on the company portal application on the end user devices. The screen snippet below shows the membership criteria for the parent group where no criteria is assigned. 1 Whereas the nested groups are already assigned with membership Criteria. See screenshot below. 2 3   To rule out device specific issues, we tested it across various platforms but none of them listed the applications that were published for download. After further research and troubleshooting we identified that the problem was related to Membership criteria inheritance. Even though we have added the membership criteria to the nested groups, the parent group ( top-level group) does not have any criteria configured. So, to resolve this issue we added the same on-premise synced security group to parent group(top-level group). Following that, we were able to see the users who are synced through Azure Active Directory and also deployed applications on the company portal for all device platforms. I hope this blog provides the general troubleshooting approach, when you are seeing similar group issues with respect to applications deployed. The key takeaway here is to understand that parent security group should have on-premise synced groups as their membership criteria in order for the nested groups to inherit and apply the same. Happy troubleshooting !!

Dheeraj Kollipara

Intune | Mobility Support Team

]]> TROUBLESHOOTING: Export error on Azure AD connector – GroupSecurityEnabledAttributeMissing https://docs.microsoft.com/archive/blogs/kolldhee/export-error-on-azure-ad-connector Tue, 22 Dec 2015 15:33:14 GMT https://blogs.msdn.microsoft.com/kolldhee/?p=1
Hello Everyone! My name is Dheeraj and I am a Support Engineer with the Mobility team, working on the Enterprise Mobility Suite of products. Few weeks ago, I worked on an interesting support issue relating to Group provisioning from On-premise to Azure Active Directory and I wanted to share this information with you. If you happen to run into this scenario, this article will help you troubleshoot and isolate the problem. Problem Statement Some of the group objects present in Active Directory on-premise were not synchronizing to Azure Active directory. While looking at the AADConnect tool, the following errors were observed in the sync operations tab whenever export run profile was executed on the Azure AD Management Agent (a.k.a Cloud Connector). “Every group requires that the Security Enabled attribute have a valid value. This attribute indicates whether the group is a security enabled group. Please set this attribute, and then try again.”   1 SecurityEnabled is a mandatory attribute which needs to be populated in order to provision a group successfully into Azure Active Directory. In this scenario, the attribute was not getting populated and we needed to find out why. Troubleshooting Steps We began by reviewing the AADConnect configuration. It was interesting to note that there were some security groups which did sync up successfully to Azure AD. So, there must be something unique about these groups that failed to provision. To understand this better, we started comparing the attributes of working security group and non- working security group. For our discussion, let’s take the groups as Group1 and Group 2. CN= Group1 (Synchronized group) CN= Group2 (Non Synchronized group) We first started searching in AD connector space with RDN “CN=Group1” and “CN=Group2” and validated if the security enabled attribute is set to True. We found that both the groups had this attribute set to true. We then validated if isCriticalSystemObject value is set, found that it is not set on non-synchronizing groups. If this attribute is set to true, then this is filtered from getting provisioned into Azure AD. Here is a snippet from a TechNet post that is referenced later on in this article. 2 That brings us to the next question – Which attributes are required at a minimum in order to get provisioned into Azure AD? This TechNet post provides an exhaustive list of all the attribute that can be synced as well as the ones that are mandatory. In the AADConnect tool, the in-flow and out-flow of these attributes are controlled by the Sync rules, which can be configured using the Synchronization Rule editor. So, that is our next stop.   Capture   We reviewed the inbound and outbound synchronization rules for Groups and compared with a default working setup from our lab. That is where we found out that the original out of the box rules were missing!! In the ‘out to AAD- Group join’ sync rule we had only 4 rules and we were missing the rule for SecurityEnabled Attribute. So, we went ahead and re-added a direct mapping for the SecurityEnabled attribute ( as shown in the screenshot below )   4   Following this, we ran the sync profiles and we could observe that the attribute was now populated and exported successfully to Azure AD! But the success was short-lived as the customer ran the configuration wizard once again and we were back to the square now. The rule got wiped out. But now, we know where exactly to look for! We went through each step in the configuration wizard and identified that the SecurityEnabled attribute was not selected in the wizard. Here is a CSV export comparison of the attribute list from an Out-of-box configuration vs the one having the problem. 1111   This can also be viewed in the UI at the Azure AD attributes section:

Non-working

7

Working

7   Typically, the attribute list is not something that we should be modifying as this would directly affect the sync rules which would then affect the synchronizations made between on-premise and Azure Active Directory. Customers are recommended not to uncheck attributes that are absolutely essential for syncing objects between On-premise and Azure. Once we re-selected the missing attribute in this wizard, the issue was resolved completely and all existing as well as new groups started to sync successfully with Azure. I hope this blog provides a general troubleshooting approach that can be taken to identify attribute-related issues while working with Azure AD connect. The key takeaway here is to understand the mandatory attributes needed for provisioning to Azure and also identify missing configurations from sync rules and wizards. Happy troubleshooting !!   Author: Dheeraj Kollipara Microsoft Mobility Team Reviewer: Karthik Divakaran Microsoft Security Support Escalation Engineer
]]>