In this day and age having an on-premise Active Directory is not mandatory, especially if you are a small and/or new organization. Most of the services will be in Microsoft 365 anyways, so why bother maintaining local AD?

If you have an Azure Active Directory Tenant, users are allowed to join Windows 10 devices to the AAD domain by default.

In the AAD Portal, under Devices > Device Settings, settings can be adjusted to the organization's needs.

Joining the device is very easy. Just open the modern Settings app in Windows 10 > Accounts > Access work or school > + Connect. Then select Join this device to Azure Active Directory.

After logging off, any user that is a member of the tenant can log in with their email address/Azure AD account.

Getting started with Microsoft 365/Exchange Online in 2021 is very easy and relatively cheap (I am paying 5 bucks a month for one mailbox and some extra stuff, like 1 TB of OneDrive storage).

Roughly speaking, here are the high level steps from beginning to end:

• Create your subscription
• Add a custom domain
• Verify the domain
• Add DNS entries for MX, Autodiscover, and SPF
• Create users
• License users
• Wait some minutes to see the mailbox in Exchange Online
• Add account in Outlook

After creating your tenant (easy to do, you can also work with a third party, instead of buying the subscription directly off of Microsoft), open https://admin.microsoft.com and select Azure AD. Unser Custom domain names, add the organization's domain.

You verify the domain by adding a TXT record to at the root of your domain. You could also verify by MX record, but usually the organization has some sort of functioning mail product, so in a migration scenario that is not an option.

@ means the root of your domain. In my case ajni.it

Due to DNS Time To Live (TTL) and caching, this might take some time.

Back to the Microsoft 365 Admin Center, under Settings > Domains select the newly added domain and then Continue setup. Add the 3 records to your DNS.

Select Add your own DNS records. For mailing, Exchange Online and Exchange Online Protection records are needed.

After correctly adding DNS records for Exchange Online, add a user in Azure Active Directory and assign the license. Very straightforward. Set usage location to your organization's country. If you do not specify a usage location, licenses cannot be assigned to that user.

Under License the license can be assigned.

You could also choose to selectively assign certain products of the subscription. Either way one license will be burned.

It takes some minutes for the mailbox to show up in Exchange Online after assigning the license.

From now on, the account can be added in Outlook or accessed through Outlook on the Web https://outlook.office365.com

If you are using Citrix MCS with Azure VMs, you might have noticed that not all the VM SKUs are available to select when creating a new Machine Catalog. With PowerShell, though, you can use any Azure VM SKUs.

If you are using Citrix Cloud, you have to download and install the Citrix Powershell SDK and login with your Citrix credentials. Optionally you could download an API client and authenticate with those credentials.

The secure client can be downloaded under Identity and Access Management > API Access > Create client. The customer id will also be shown on that page.

You authenticate with the API client this way:

Set-XDCredentials -CustomerId "customername" -SecureClientFile "C:\temp\secureclient.csv" -ProfileType CloudAPI

Otherwise, without API credentials, after executing the first command, you will be asked to insert your Citrix credentials:

Now the commands to change the Citrix MCS VM type.

Get-ProvScheme -ProvisioningSchemeName "CatalogName"

Take note of the folder name after XDHYP:\HostingUnits\ under MasterImageVM.

This command will register the virtual drive XDHYP:\ in PowerShell:

Set-HypAdminConnection

Insert that folder name in this command:

Set-ProvScheme –ProvisioningSchemeName "CatalogName" –ServiceOffering "XDHyp:\HostingUnits\Foldername\serviceoffering.folder\Standard_NV4as_v4.serviceoffering"

Delete and re-create the VM. The right VM type will be then used.

Normally, adding an Availability Set after the VM has been deployed is not possible. You would have to delete the VM, leaving the NIC and OS disk intact and then re-creating the VM with the Availability Set. Of course that can be done manually, but there is a PowerShell script that does this all for us.

This can be all done in the Azure Cloud Shell, you do not have to install the PowerShell Module on a Windows Machine.

Install-Module AzureRm.AvailabilitySetManagement

Create an AS before adding the VM to the AS.

New-AzureRmAvailabilitySet -Location "West Europe" -Name "myAs" -ResourceGroupName "myRg" -Sku aligned -PlatformFaultDomainCount 3 -PlatformUpdateDomainCount 5

Now add the VM to the AS:

Add-AzureRmAvSetVmToAvailabilitySet -ResourceGroupName "myRg" -VMName "VM01" -OsType windows -AvailabilitySet "myAs"

This will stop the VM if it is running, delete the VM item (leaving the NIC and OS disk intact) and re-create that with the same VM size inside the newly created Availability Set.

References:

https://pixelrobots.co.uk/2018/02/add-existing-virtual-machine-availability-set-azure/

https://gist.github.com/PixelRobots/3c34027d225c7acb09833840b7258ee9#file-movevmavaset-ps1

An Azure Service Principal is a service account created in Azure AD and can be leveraged in PowerShell scripts for automation. It is recommended to use Service Principals for security reasons since they have separate credentials and very constrained rights.

You can either use password-based authentication or certificate-based authentication with Service Principals. In this article, only password-based authentication is covered. Certificate-based authentication is treated in the Microsoft article linked at the end of the page.

First of all, the Az Powershell Module is needed.

Install-Module -Name Az -AllowClobber -Scope Allusers

If you have multiple subscriptions, make sure you have selected the correct one.

Get-AzSubscription

Select-AzSubscription -SubscriptionId xxxxxxxxx

Now create the Principal:

$sp = New-AzADServicePrincipal -DisplayName PowershellAutomation

The $sp object contains a secret parameter (the password), which is not in clear-text and an ApplicationID, that will be used as the username. To decrypt the secret parameter use the following commands:

$BSTR = [System.Runtime.InteropServices.Marshal]::SecureStringToBSTR($sp.secret)
$UnsecurePassword = [System.Runtime.InteropServices.Marshal]::PtrToStringAuto($BSTR)

In a script the $UnsecurePassword should not be hardcoded, instead, it should be saved as an encrypted XML file and decrypted when the script is executed. I wrote a post about securing credentials in PowerShell scripts, check it out: https://www.ajni.it/2020/05/powershell-encrypt-and-store-your-credentials-securely/.

Logging in is also straightforward. The Tenant id can be retrieved in the main page of Azure AD.

Connect-AzAccount -ServicePrincipal -Credential $credentials -Tenant xxxxx

When assigning rights, the newly created identity will be listed:

References:

https://docs.microsoft.com/en-us/powershell/azure/create-azure-service-principal-azureps?view=azps-3.8.0