You can easily run one or multiple programs at logon without messing with the Registry by using Group Policy Object (GPOs).

Under User (or Computer) configuration > Administrative Templates > System > Logon > Run these programs at user logon you can insert the path of the executable. Very clean and straight forward.

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.