Use Custom Attributes for automatically populate Azure AD Dynamic Group Memberships

March this year the Active Directory team announced Attribute Based Dynamic Group Membership for Azure AD. Until then, group membership was a manual thing that had to be done for each user. With this feature you can specify a rule on an Azure AD security group that will automatically manage the membership of that group based on user’s attribute values. Dynamic Group Membership is supporting by default a subset of user attributes which can be used.

image

But what if you use in your organization custom attributes for various applications-, business- and provisioning processes? In this blog post we go further and will explain how to use custom AD attributes, extend your Azure AD tenant and use these custom attributes to automatically populating a security group.

Continue reading “Use Custom Attributes for automatically populate Azure AD Dynamic Group Memberships”

Integrate your Microsoft Intune device enrollment with Azure AD!

May this year Microsoft announced a new capability of automatically enroll devices in Microsoft Intune as part of joining devices in to Azure AD (Premium). By joining a Windows 10 device to Azure AD it is extremely easy for end users to get the benefits of single sign-on, OS state roaming, and management capabilities.

image

This will work with both Microsoft Intune and with 3rd party MDM solutions. In this blog post I’ll show you how ease and transparent this process is and how powerful the integration is of Microsoft Online Services and Windows 10!

Continue reading “Integrate your Microsoft Intune device enrollment with Azure AD!”

Assign EMS licenses based on Local Active Directory Group Membership

 

 

As all roads lead to Rome there are many ways to assign Enterprise Mobility Suite (EMS) licenses to end-users. This can be a manual process or automated by using PowerShell. Both options have in common that you must be a global administrator of your Azure subscription to assign these licenses.

The majority of the available public resources and publications describes the (manual) process bassed on per user- or group assignment through the Azure Management Portal. Downside of assigning EMS licenses through the Azure Management Portal or by PowerShell is that you must be a member of the global administrator user role. A right you want to keep to a limited number of accounts, further these accounts are often not responsible for such tasks as assigning licenses.

Continue reading “Assign EMS licenses based on Local Active Directory Group Membership”

Keep your Service Manager CMDB in accurate shape!

One of the big advantages of using Service Manager as your Configuration Manager Database (CMDB) is the connector framework. By using the connector framework you are able to establish out-of-the box connections to your infrastructure – Active Directory – and System Center components like Configuration Manager-, Operations Manager and Virtual Machine Manager. Hereby you can easily gather and centrally store all relevant information into a single place which forms the basis for your IT Service Management (ITSM) processes.

One of the major challenges of a CMDB is to keep the – information contains – up to date and accurate. Also herein the connector framework have an important role to (automatically) update Configuration Items (CI) from different sources (connector framework).

A while ago Travis Wright (who else…) wrote a blog post regarding the behavior of what happens with CI’s in the CMDB when deleted from Active Directory and what permissions are required by the run-as account that is used for the AD connector.

In this post I’ll walkthrough how to configure and set proper rights for the run-as account used by the AD connector. Continue reading “Keep your Service Manager CMDB in accurate shape!”

AD System Discovery causes crashdumps

Last week I was confronted with the fact that smsexec services was collapsed at one of the ConfigMgr servers. My first thought was to analyze the server logs. What struck me was the presence of the crash dumps folder. This corresponds to the new crash dump sub-directories wich contains smsexec as part of the description.
crash.log

The crash.log pointed me to Active Directory System Discovery as the culprit. When checking the AD System Discovery properties, I discovered a typo of a custom attribute pwdLastSt.

AD System Discovery attribute properties

After corrected typo (pwdLastSet) and run an AD System Discovery cycle…no crashdumps anymore :-) Problem solved!