How cool would it be to automate your daily SQL tasks using Azure Automation? Well, really cool off course! So lets start using Azure Automation! So go ahead, if you don’t have an automation account yet, create one by going to Automation Accounts.
Give your automation account an name, choose a subscription, resource group and a location and hit the create button!
When you migrate to Azure SQL, you might think that Azure does all SQL maintenance, including the maintenance of your database… But the truth is, you will need to setup some maintenance yourself for your databases. Microsoft doesn’t know what is best for your application or database. With this manual you should be able to setup basic database maintenance on Azure SQL.
By default everyone may create a new team in Microsoft Teams. As an organisation admin you might want to control this, or release it a some point. With this manual you should be able to lock down team creation to users that are member of a Azure AD Security group.
STEP 1: First we will need to install the Preview version of the Azure Active Directory PowerShell module for Graph. Open a PowerShell window with Adminstrator privileges and run the following 2 commands:
The result of the script should give you the updated settings. On the last line you should see EnableGroupCreation. If you want to reverse this setting. Just simply change the following line to True and run the entire script:
$AllowGroupCreation = “True”
If you want another security group, rerun the script with the new group name.
So you want to clean up unused (shared) mailboxes in your Exchange (Online) environment. How to find out which mailboxes have been inactive for a long time? The answer is yet simple again, with a cool Power Shell script.
Next, we just need to change the 2 value’s below, and run it. After running, you don’t get a confirmation. It might take up to 30 minutes before changes are visible in all Office 365 and/or Azure portals.
With the move to the cloud there might be a time where you would like to remove the Active Directory link (AD Connect) and go for a cloud only strategy. With a few simple steps you can disconnect the AD connect sync from Azure AD.
When you look in your Office 365 environment you will notice that the sync status has different symbols. One for cloud only, and one for Active Directory. To disable the link, open a PowerShell window and run the following steps.
STEP 1: First make sure that you disable the AD Connect sync service by disabling the service, or set it to staging mode.
STEP 2: Connect to your Microsoft Office 365 environment using the following command, and login to the desired environment:
STEP 3: Now run the following command to disable the sync, confirm your actions, you cannot undo this change!
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