There are situations where you would like to enforce an update of the Exchange Global Address list (GAL) in Office 365. With a few steps this can easily be done!
STEP 1: First we will need to make sure that our admin account has the correct permissions. Go to the Exchange Online Admin center, and then to permissions – admin roles and click on the + sign to add a new role
We will now create a new role group. Give it the name Address List Management and assign the role Address lists, and make sure to add the administrator account as a member. Click Save when ready.
When you create a new Office 365 tenant, all user mailboxes will have the default timezone and language. In my case, I work in the Netherlands, the preference for most companies is to set the Time zone to Central European Time (GMT +1) and the language of the users default folders to Dutch.
You can either ask the users to logon to webmail using https://outlook.office.com and fill in the first time question to set the time zone and default language. But how cool would it be to do this for all your users using PowerShell?
When you’re migrating from one Exchange environment to another, or from on-premise to Exchange online without using the hybrid setup, the most forgotten part is the migration of the users x500 address. The reason why this is so important is because Exchange uses this to deliver local emails instead of the SMTP address that is normally associated with email. (This also goes along for calendar appointments)
So, by not migrating the x500 address it means that communications will fail when changing calendar appointments, or replying on old emails. To prevent this we will need to export the ExchangeLegacyDN from Active Directory, and import it again as a ProxyAddress in Active Directory.
Export the x500 address (ExchangeLegacyDN)
Step 1: From your source Active Directory, look up the distinguishedName, and copy the content of the value.
In a new Exchange (Online) environment you might want to change the default calendar sharing permissions for all users. By default the sharing permissions for the entire organization are set to “Can view when I’m busy”.
Some companies have a different wish on the default calendar settings of their users. The preferred setting might be “Limited details”. This will show just the headlines and location of the calendar.
If you try to open an invite, it will notify that you do not have access.
So, what options do we have? From the Outlook app you can see that there are 5 options to choose from. (See screenshot below)
A commonly heart end-user frustration with Auto-mapped shared mailboxes is that Send emails from the shared mailbox end up in the send items of the user it self. In the past you would need to set a registry key on the client computer to get this resolved. But with Office 365, there is an easy way to change this behavior for every user.
With PowerShell this job is done in less than a minute in just 2 simple steps.
STEP 1: First connect to Exchange Online using the following commands:
With the transition to Azure AD, you might want to connect your AAD joined devices to the traditional file server as explained in this article: Go Azure AD Joined with on-prem DC and fileserver The next step is to map some network drives with Intune!
Step 1: The first step is to create a PowerShell script that will do the actual drive mappings. This script will be placed on a Azure Blob storage (or your internal domain) where you will be able to manage and maintain the script. This script will be run using a second script that we will deploy with Intune. For your convenience I’ve already prepared the script:
In this manual I will explain step by step how to migrate your users from their personal drive to OneDrive using bulk migration in SharePoint Migration tool. This includes preparing the users OneDrive, granting permissions, and setup SharePoint Migration tool.
Before we begin, we will need a migration station, I would recommend to use a server designed for this purpose. On the migration server make sure you install the following:
When you accidentally locked your self out from a Virtual Machine in Azure, there is no console access to login and help your self back in to the system.
In the last year I’ve seen a few cases where somebody accidentally locked himself out of a VM by wrongly adjusting the Windows Firewall, making it impossible to manage their virtual machine in Azure. But with Custom script extension it is possible to disable the Windows Firewall to gain access again!
Recently we created an AAD tenant that has no on-premises AD domain counterpart. Now we are facing an issue where we want to be able to use the identities in this tenant to log into some servers. It would appear that we would need to domain join these servers, but we can’t do this without AD. The question is, how can we continue to setup these servers?
But today we are going to install a new domain on-premise. The domain name isn’t relevant for the sync with Azure AD / Office 365. But the UPN for the end users is important! So first we can add the UPN domains by going to the Domain and Trusts console. Add the required domain names.
If you ever had to restore a domain joined machine, or a laptop/desktop that didn’t connect to the domain in a long time, it might happen that the domain relationship is broken. When you try to logon you get the following error:
“The trust relationship between this workstation and the primary domain failed.”
What you can do is leave the domain, and rejoin the domain, however, it is better to reestablish the trust relationship. Log in on the computer with a local admin account and run in a privileged PowerShell window the below script. After running a reboot should do the trick.
Use the following command to re-establish the trust with the domain:
$domaincontroller = “Name of the domain controller” $credential = Get-Credential