Eugh. Configuring Powershell for remote Exchange management

Tue, May 19, 2020 4-minute read

I use a mixture of Mac and Linux for most of my needs. I’ve run Windows virtual machines of same flavour or another but since .NET core 3 landed I’ve barely had to do even fire it up. There’s nowadays very little you can’t do in a non-Windows environment.

That doesn’t really extend (yet?) to remote administration of your Office365 tenant using Powershell.

I’m trying to configure some DNS bits for one of our domains that needs the Exchange Online V2 Powershell module. Come with me as I disappear down a rabbit hole of getting this working.

(I know Powershell for macOS is a thing; but I’ve not yet experimented with it. Maybe I will if I can (or can’t!) get this working.

I fired up a dust ol’ Win10 virtual machine and started following the guide. Windows Powershell was in the start menu so gave it a go. No idea what version so

$host.version

gave me 5.1.16299.98. That ought to do nicely? Onwards!

winrm quickconfig

This is required to allow an exception in the Windows firewall. But doing it the first time failed. Yep, you need to run Powershell as Administrator. Wakey wakey.

OK, so running as Admin and:

WinRM is not set up to receive requests on this machine.
The following changes must be made:
Start the WinRM service.
Set the WinRM service type to delayed auto start.

Make these changes [y/n]?

Hit ‘y’ and… a wall of error:

Message = WinRM firewall exception will not work since one of the network connection types on this machine is set to Public. Change the network connection type to either Domain or Private and try again.

OK, so in my case I’m in a virtual machine so I have a couple of network adaptors, including one virtual which was set to public but otherwise doing nothing. Disabling that allow the firewall exception to go in. Following the rest seemed to say this was working.

The rabbit hole opens

Onwards to ‘installing the Exo V2 module’. Step 1: you need PowershellGet. Innocuous looking sub-link. OK.

Before updating PowerShellGet, you should always install the latest NuGet provider.

OK

Install-PackageProvider -Name NuGet -Force

gives

WARNING: MSG:UnableToDownload «https://go.microsoft.com/fwlink/?LinkID=627338&clcid=0x409» «»
WARNING: Unable to download the list of available providers. Check your internet connection.
WARNING: Unable to download from URI 'https://go.microsoft.com/fwlink/?LinkID=627338&clcid=0x409' to ''.
Install-PackageProvider : No match was found for the specified search criteria for the provider 'NuGet'. The package
provider requires 'PackageManagement' and 'Provider' tags. Please check if the specified package has the tags.
At line:1 char:1
+ Install-PackageProvider -Name NuGet -Force

Now, there are actually a couple of things going on here; one a lack of repositories to get stuff from AND ALSO a TLS error. I ‘fixed’ the TLS error first:

[System.Net.ServicePointManager]::SecurityProtocol=[System.Net.SecurityProtocolType]::Tls12

and you should now be able to install NuGet:

 Install-PackageProvider -Name NuGet -Force

Name                           Version          Source           Summary
----                           -------          ------           -------
nuget                          2.8.5.208        https://onege... NuGet provider for the OneGet meta-package manager

If you now try and install PowerShellGet:

Install-Module -Name PowerShellGet -Force

It might work… but also it might not:

PackageManagement\Install-Package : No match was found for the specified search criteria and module name
'PowerShellGet'. Try Get-PSRepository to see all available registered module repositories.

If you follow its advice and do a

Get-PSRepository

this is a bit of a clue:

PS C:\WINDOWS\system32> Get-PSRepository
WARNING: Unable to find module repositories.

SO let’s give it some:

Register-PSRepository -Default

and once again:

PS C:\WINDOWS\system32> Install-Module -Name PowerShellGet -Force
PS C:\WINDOWS\system32>

And we’ve now actually got PowerShellGet. Hurrah.

PS C:\WINDOWS\system32> Set-ExecutionPolicy RemoteSigned

Execution Policy Change
The execution policy helps protect you from scripts that you do not trust. Changing the execution policy might expose
you to the security risks described in the about_Execution_Policies help topic at
https:/go.microsoft.com/fwlink/?LinkID=135170. Do you want to change the execution policy?
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [S] Suspend  [?] Help (default is "N"): y
PS C:\WINDOWS\system32> Install-Module -Name ExchangeOnlineManagement

Untrusted repository
You are installing the modules from an untrusted repository. If you trust this repository, change its
InstallationPolicy value by running the Set-PSRepository cmdlet. Are you sure you want to install the modules from
'PSGallery'?
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [S] Suspend  [?] Help (default is "N"): y
PS C:\WINDOWS\system32>

This all seemed to go OK.