Sync AD Groups with Microsoft Teams (BETA)

Microsoft Teams doesn’t allow you to define a group for membership (dynamically).
When you add an Azure AD group to a Team, all users will be added once.
Once someone is added to that group, it won’t be added to the team automatically.

For this I created this script.
You define an Active Directory group and a Microsoft Team to manage.
All users that are in the AD group, but aren’t in the Team will be added (as a member).
All users that aren’t in the AD group, but are in the Team will be removed from the Team.
Offcourse except owners.
If an owner is in the Team, but isn’t in the AD Group it will generate a warning and continue.

You can find it on Technet Gallery:

Step 1:
Create an Service Account in your Active Directory domain.
This service account needs an UPN suffix with a verified Office 365 domain.

For example: It can be, but cannot be user1@contoso.local.
Where is added as a verified domain in Office 365.

Sync your Active Directory domain with Azure AD (it normally does every 30 minutes automatically).
Also make sure the Service Account has read-rights in your Active Directory.

Step 2:
Go to Office 365 and add an Office 365 license to the Service Account (with the Teams subscription).

Step 3:
Go to and add the service account as an owner of the Teams you want to manage from AD.

Step 4:
Add the users of the Teams you want to manage to the AD groups you want to sync.

Step 5:
Add AD Groupname and Team name you want to sync to Teams.csv (example csv is in the zip-file), with a comma as a delimiter.
Every line is an Active Directory group and Team that needs to be synced.


Step 6:
Run Powershell as the service user and browse to the location.
run Set-SecureTeamUserInfo.ps1 and type in the credentials of the service account (UserPrincipalName, not SamAccountName).
Credentials are now securely saved in the folder so the script can sign in to Office 365.

Posted in Scripts, Teams



Problems with WSUS on Server 2016

Yesterday I have had an issue with computers not reporting to a newly installed WSUS server.
However targeting worked (computers where placed in the right Computer folders in WSUS), computers wouldn’t report. 

When I looked into the ReportingEvents log in C:\windows\SoftwareDistribution folder, it showed a error “Windows Update Client failed to detect with error 0x8024401c”.
However this error wasn’t consistent (sometimes it did succeed, but it mostly didn’t)
It looked rather odd. 

Browsing the web more people are talking about issues in IIS.
So this was the issue: 

On Windows Server 2016, the “Private Memory Limit (KB)” was set to 1.8GB.  

You should reset it to 0, so that WSUS can decide the memory usage of the WSUS Application Pool.
Once set, all issues with WSUS were gone.
Computers started reporting in immediately (off course this depends on the reporting configuration in your Group Policies). 

Deploying an RDS farm in an Server Core environment

Note: The RD Web Access role requires Desktop Experience; In Server 2016 you can’t change between core and desktop anymore. 

First of all, I have made a script that will install and configure all roles and tools.
It installs the management tools on the server which the script runs on (from this server you can manage the core RDS environment).
Then it will ask on what servers which roles needs to be installed.
Find it on Technet 

After everything is installed, add the servers to server manager on the management server.
However already installed and configured, you need to add the license server and RD Gateway to the farm.
It is already connected to the Connection Broken, but are not automatically detected by Server Manager. 

Afterwards you should use Server Manager to add certificates to the RD Access Roles.
I would use a Wildcard certificate for RD Gateway and RD Web Access, since they are accessed over the internet.
Certificates for the broker role can be issues by your own CA, or if you use a public domain name in your internal domain (example, I would request an additional wildcard certificate for your internal domain. 

The first part of the installation can be accomplished by following the steps in the RDS Farm setup script, the second part you’ll need to do using Server Manager. 

Saving on certificates in an multi-tenant Exchange environment

By default, alot of companies buy certificates for Exchange based on the domains that are added to Exchange.
While a company is expanding, it can be very expensive.

In an organization using enormous amounts of domains, it can be challenging to keep up with certificates.
These issues you don’t have with Office 365, since Microsoft is responsible for Autodiscover.

When hosting your own multi-tenant Exchange environment, you can actually use an SRV record instead of an CNAME or A record.
This way it will announce that the corresponding service is hosted elsewhere.

This way you only need the (likely wildcard) certificate of the providing company.
You have an serviceprovider called Adatum Services, which hosts
The IT admin adds a domain ( to the multi-tenant Exchange environment.
Instead of adding an A record to the Exchange Client Access Server, you add an SRV record telling the Outlook client that the Autodiscover service is hosted elsewhere: on

The record for would look as:
Name: @
Protocol: TCP
Port: 443
Service: _Autodiscover
Priority: 10
Weight: 1

Now you don’t have to make changes to your certificates, everytime an domain is added to your Exchange environment.

Posted in Collaboration, Exchange (General)



User interaction script for SCCM

This script (made by me) allows you to use user-interaction to notify your users about an installation or update of software.
It also allows you to push an installation (with administrator priviliges), while still including the user in the process.

If there is no interaction within 20 seconds per notification, it will go on.

You can also specify a process to check, and notify the user that the application needs to be closed to continue the installation (if the process is running off course).
It will re-check every 20 seconds, but will not continue until the process is closed.

This means that if the user isn’t behind his/her desk, and nothing conflicting is running, it will continue.
This makes the process of installing and updating software a lot more user friendly, but will not compromise compliance.

Download from Technet