PowerShell Script for Adding Partner Admin Link (PAL)

partner Admin Link (PAL) Overview


Microsoft partners provide services that help customers achieve business and mission objectives using Microsoft products. When acting on behalf of the customer managing, configuring, and supporting Azure services, the partner users will need access to the customer’s environment. Using Partner Admin Link, partners can associate their partner network ID with the credentials used for service delivery. Microsoft wants to recognize your influence on Azure consumption to deepen the partnership, build your business, and highlight your expertise.

Get Recognized for Driving Azure Consumption (Microsoft Video)

Ways To Setup Partner Admin Link (PAL)

Can be setup via:

  • The Azure Portal
  • PowerShell
  • CLI

Further documentation

Best Practice
  • Activate Partner Admin Link whenever possible (in both incentive and non-incentive scenarios) as this maximises the demonstration of influence on customer Azure consumption.
  • PAL is not retrospective, so it is best to do this on day 1 of an engagement.
  • Automate where possible (i.e. PowerShell or CLI), Azure Portal as the fallback.
  • Link all accounts that have access to customer resources (as some accounts may have different scopes of permissions, some accounts may drop off over time, etc).
  • Use a Location or HQ based MPN ID (not Virtual Org).

PAL is linked on a per user, per tenant basis.

The bit you came here for (powershell script)!

At DevOpsGroup we need to ensure that each time we begin a new Azure engagement we are linking our MPN ID. As this should happen the first time we are logging into a customers environment for every user, we wanted to make it as simple as possible.

I created this script so you are guided through the process in a simple, user friendly manner and it validates that the ID has been set / changed.

As a quick run through the code does the following:

  • Creating Log File & Start Transcript
  • Check Required Modules Are Installed, if not, install them
  • Connect To Azure Account
  • Collect Tenant ID (You are presented with a grid view selector of Tenant ID’s you have access to)
  • Collect New MPN Partner ID (Just press enter if you add your default as explained below)
  • Validation of existing MPN ID (If it exists) and confirmation if you want to update it
  • Validation of new MPN ID if new one is set / changed
The code is mostly self explanatory and has been commented. However, you may want to change this value:
$defaultValue = “1234567”

I would have this set to the DevOpsGroup MPN ID, so when it asks you for your ID, you can just hit enter to accept the above default. While this is the default, it still gives you the flexibility to enter a different ID and use that instead.

Big thanks to Bob Larkin for his QC work and suggesting the gridview!

Hope you find this useful, please feel free to fork and use!







Please follow and like us:

Automating Windows environments setup with Boxstarter and Chocolatey packages

Chocolatey is command line package manager for Windows that gives you a very Linux -esque software installation experience. This guide expects that you already are using Chocolatey, but in case you need convincing here’s what makes it so awesome, for example: choco install googlechrome will install Google Chrome on your computer without having to wait for the installer. You can even get fancy and list as many packages as you would like with a -y flag to automatically accept any prompts: choco install -y azcopy firefox awscli Can’t undersell how easy this makes to set a computer up for the first time.

Boxstarter uses Chocolatey packages but adds a few extra tools that allow you to install software faster and make changes to Windows settings. Boxstarter has some amazing functionality that I am not going to touch on here, but I would recommend Checking out their Docs.

Boxstarter  is now being managed by Chocolatey. Boxstarter.org still exists, but the source repository is now under the Chocolatey org on Github.

Microsoft are contributing Boxstarter scripts in a new Github repo – https://github.com/Microsoft/windows-dev-box-setup-scripts

If you’re looking to use Boxstarter to automate the software installation of your Windows machines, there’s a few tricks and traps worth knowing about. The below sections came from the awesome David Gardiner and the comments to the issue he raised in the repo:

Avoid MAXPATH errors

It’s worth understanding that Boxstarter embeds its own copy of Chocolatey and uses that rather than choco.exe. Due to some compatibility issues Boxstarter currently needs to embed an older version of Chocolatey. That particular version does have one known bug where the temp directory Chocolatey uses to download binaries goes one directory deeper each install. Not a problem in isolation, but when you’re installing a lot of packages all at once, you soon hit the old Windows MAXPATH limit.
A workaround is described in the bug report – essentially using the --cache-locationargument to override where downloads are saved. The trick here is that you need to use this on all choco calls in your Boxstarter script – even for things like choco pin. Forget those and you still may experience the MAXPATH problem.

To make it easier, I add the following lines to the top of my Boxstarter scripts:

$ChocoCachePath = “C:\Temp”
New-Item -Path $ChocoCachePath -ItemType directory -Force

And then I can just append –cacheLocation $ChocoCachePath to each choco statement. eg.

cup docker-desktop –cacheLocation $ChocoCachePath
cup docker-compose –cacheLocation $ChocoCachePath
cup minikube –cacheLocation $ChocoCachePath

Avoid unexpected reboots

Detecting and handling reboots is one of the great things about Boxstarter. You can read more in the docs, but one thing to keep in mind is it isn’t perfect. If a reboot is initiated without Boxstarter being aware of it, then it can’t do its thing to restart and continue.

One command I’ve found that can cause this is using Enable-WindowsOptionalFeature. If the feature you’re turning on needs a restart, then Boxstarter won’t resume afterwards. The workaround here is to leverage Chocolatey’s support for the windowsfeatures source. So instead of this

Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V-All

Do this

cinst Microsoft-Hyper-V-All -source windowsfeatures

If you have a more intricate Boxstarter script, you may run into some problems that you need to diagnose. Don’t look in the usual Chocolatey.log as you won’t see anything there. Boxstarter logs all output to its own log, which by default ends up in $env:LocalAppData\Boxstarter\Boxstarter.log. This becomes even more useful when you consider that Boxstarter may automatically restart your machine multiple times, so having a persistent record of what happened is invaluable.
The other things you might want to make use of is Boxstarter-specific commands like Write-BoxstarterMessage (which writes to the log file as well as the console output) and Log-BoxstarterMessage (which just write to the log file)

Find out more about these and other logging commands by running help about_boxstarter_logging.

My scripts

I keep my Boxstarter scripts at https://gist.github.com/flcdrg/87802af4c92527eb8a30. Feel free to have a look and fork them if they look useful.

how to use

Whenever I need to build a new laptop, I just run the following 2 commands:

. { iwr -useb http://boxstarter.org/bootstrapper.ps1 } | iex; get-boxstarter -Force

The above installs BoxStarter

Followed by this in an elevated PowerShell command prompt:

Install-BoxstarterPackage -PackageName https://gist.githubusercontent.com/ghostinthewires/033276015ba9d58d1f162e7fd47cdbd3/raw/boxstarter.ps1 -DisableReboots

This downloads the file from the gist and begins installing everything

Hope this was helpful!

Any questions just get in touch via Twitter

Please follow and like us: