You probably have stumbled upon this common problem: When logging into a Domain Computer with a Domain user, this error appears: The trust relationship between this workstation and the primary domain failed.

What does it mean? Well, it basically means that the Domain Computer cannot authenticate against Active Directory, because the Computer Account password on the workstation is not valid anymore (this can occur when using Sytem Restore or when restoring from a backup).

How do you solve this issue? Pretty easy. Just remove the computer from the Domain and re-join. That works, but there is a cleaner and faster solution with one line of PowerShell code:

Test-ComputerSecureChannel -Repair -Credential (Get-Credential)

You will need to enter domain user credentials that can create or modify computer accounts in the Active Directory Domain.

You can check if the password of the Domain computer changed by viewing the attribute pwLastSet in the Attribute Editor.

If a computer is in an Active Directory Domain environment with Exchange On-Prem installed, Outlook clients might connect to local Exchange instead of Exchange Online, because they query Active Directory first.

This Registry key will avoid SCP Lookup in Active Directory.

HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover
DWORD ExcludeSCPLookup 1

If you are curious, SCP is located here (you can view it with ADSIEdit inside the Configuration Partition):

CN=Services, CN=Microsoft Exchange,CN=Organization, CN=Administrative Groups,CN=Exchange Administrative Group, CN=Servers,CN=YourServer,CN=Protocols,CN=Autodiscover,

References:

https://jacob.gardiner-moon.co.uk/2016/06/13/outlook-autodiscover-connecting-local-exchange-server-instead-office-365/

If you ever need to copy NTFS permissions of a folder, there is a quick PowerShell one-liner that will save your day:

Get-Acl C:\SourceFolder| Set-Acl D:\DestinationFolder

Have fun!

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