{"id":4690,"date":"2022-02-03T14:20:05","date_gmt":"2022-02-03T12:20:05","guid":{"rendered":"https:\/\/www.msb365.blog\/?p=4690"},"modified":"2023-06-23T13:01:07","modified_gmt":"2023-06-23T11:01:07","slug":"powershell","status":"publish","type":"post","link":"https:\/\/www.msb365.blog\/?p=4690","title":{"rendered":"PowerShell Script for creating License Groups including assignments"},"content":{"rendered":"

Since I rely heavily on standardization for my clients, I have created a new script that I would like to share with you here.
\nYou can find the GitHub link at the end of this article.<\/p>\n

Why does it make sense to create and manage licence groups in a standardized and automated way?<\/p>\n

There are several reasons: One of them is that the landscape looks the same or similar when looking after several customers.<\/p>\n

On the other hand, this is faster and the error rate when creating and assigning licences is practically eliminated.
\nThe aim of this script is to create the most commonly used licence groups on-premise, then synchronize them in the direction of Azure Active Directory and automatically carry out the corresponding licence assignment.<\/p>\n

It is important that the required licences are already available in the M365 tenant before this script is executed.
\nHere is the documentation on how this script works:<\/p>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
\"\"<\/a><\/td>\nAs already mentioned, the required licences must already be available in the tenant.<\/p>\n

Furthermore, it must be ensured in advance that the OU where the licence groups are to be created is already preconfigured in the Azure AD connect.<\/p>\n

\u00a0<\/p>\n

Once these two points have been prepared, the script can begin.<\/td>\n<\/tr>\n

\"\"<\/a><\/td>\nAfter executing the script, it first checks whether the Active Directory module is already present. Since I recommend executing this script on a domain controller, there should be no problems here.<\/td>\n<\/tr>\n
\"\"<\/a><\/td>\nThe next step is to set the only variable. This is the OU path where the licence groups are to be created. How to enter this variable is shown in yellow as an example in the prompt.<\/td>\n<\/tr>\n
\"\"<\/a><\/td>\nNow the licence groups are created on the on-premise Active Directory. As shown in the picture, it can happen that certain groups cannot be created. These are highlighted in colour.<\/p>\n

\u00a0<\/p>\n

The reasons why this is the case must be analysed accordingly. In this example, the reason is that these groups already exist.<\/td>\n<\/tr>\n

\"\"<\/a><\/td>\nAfter the creation of the groups is completed, a summary is shown of which of the groups have actually been created.<\/td>\n<\/tr>\n
\"\"<\/a><\/td>\nThe next step is to try to run an Azure AD sync.<\/p>\n

\u00a0<\/p>\n

If this is successful, we get a message that looks like this screenshot.<\/td>\n<\/tr>\n

\"\"<\/a><\/td>\nIf there is no Azure AD connect installed on the system where the script is executed, this message will be displayed.<\/p>\n

This means that either a manual sync must be initiated or we must wait until the autosync has been performed before we can continue.<\/td>\n<\/tr>\n

\"\"<\/a><\/td>\nAfter the sync between on-premise and the Azure Active Directory has been successfully completed, we now have to log in to the Azure Active Directory via PowerShell.<\/p>\n

\u00a0<\/p>\n

This script checks whether the corresponding PowerShell module is installed, if this is not the case, the module is installed first before continuing.<\/td>\n<\/tr>\n

\"\"<\/a><\/td>\nThen we have to log in to the module with the appropriate credentials.<\/td>\n<\/tr>\n
\"\"<\/a><\/td>\nThe same process as for the Azure Active Directory PowerShell module is also carried out for the second module. This is the Azure Licensing Module. If this is not available, it is installed first and then we can log in.<\/td>\n<\/tr>\n
\"\"<\/a><\/td>\nNow the script checks which licences are available in the tenant and links them to the corresponding licence group that was previously created and synced on-premise.<\/td>\n<\/tr>\n
\"\"<\/a><\/td>\nAfterwards, the script points out again that assignments have only been made for those groups that also have a corresponding licence.<\/p>\n

It also refers to a corresponding Microsoft Technet article.<\/p>\n

\u00a0<\/p>\n

This article can be opened directly from the script. Select \u201cY\u201d if you want to, or \u201cN\u201d if you do not want to.<\/td>\n<\/tr>\n

\"\"<\/a><\/td>\nIf we continue with the selection \u201cY\u201d, the corresponding Technet link from Microsoft is called up.<\/td>\n<\/tr>\n
\"\"<\/a><\/td>\nAfter that, the script is complete.<\/td>\n<\/tr>\n
\"\"<\/a><\/td>\nAs a review, we see the created groups with the corresponding description in the on-premise Active Directory. Here we can now add our users to assign a corresponding licence.<\/td>\n<\/tr>\n
\"\"<\/a><\/td>\nAlso on the Azure Active Directory page we see the corresponding synced groups.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

\u00a0<\/p>\n

I hope this script helps you to take another step towards automation.<\/p>\n

However, I recommend that you run this script in a LAB the first time you use it. You have all rights to adapt and reproduce this script for your own use. However, you do not have the right to sell this script to third parties.<\/p>\n

\u00a0<\/p>\n

You can find the script here on my GitHub<\/strong><\/a> page.<\/p><\/blockquote>\n

\u00a0<\/p>\n

Have fun with it\u2026<\/p>\n

\ud83d\ude42<\/p>\n

\u00a0<\/p>\n","protected":false},"excerpt":{"rendered":"

Since I rely heavily on standardization for my clients, I have created a new script that I would like to share with you here. You can find the GitHub link at the end of this article. Why does it make sense to create and manage licence groups in a standardized and automated way? There are […]<\/p>\n","protected":false},"author":1,"featured_media":4692,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_crdt_document":"","om_disable_all_campaigns":false,"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"_uf_show_specific_survey":0,"_uf_disable_surveys":false,"footnotes":""},"categories":[685,12,1923,3],"tags":[],"class_list":["post-4690","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-active-directory","category-azure","category-microsoft-365","category-powershell"],"post_mailing_queue_ids":[],"_links":{"self":[{"href":"https:\/\/www.msb365.blog\/index.php?rest_route=\/wp\/v2\/posts\/4690","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.msb365.blog\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.msb365.blog\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.msb365.blog\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.msb365.blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=4690"}],"version-history":[{"count":6,"href":"https:\/\/www.msb365.blog\/index.php?rest_route=\/wp\/v2\/posts\/4690\/revisions"}],"predecessor-version":[{"id":4714,"href":"https:\/\/www.msb365.blog\/index.php?rest_route=\/wp\/v2\/posts\/4690\/revisions\/4714"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.msb365.blog\/index.php?rest_route=\/wp\/v2\/media\/4692"}],"wp:attachment":[{"href":"https:\/\/www.msb365.blog\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=4690"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.msb365.blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=4690"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.msb365.blog\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=4690"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}