OnedriveMapper v3.11 release

Version 3.11 of OneDriveMapper has been released:

  • additional fixes to Microsoft’s new sign in method

Important Auto Update Instructions

This version can only auto-update from a cleanly installed v3.10, lower versions will need to be reinstalled.

New Azure AD Signin experience

In IE mode, the script now redirects to the old experience, this means that IE mode will BREAK once Microsoft enforces the new experience. They have not released a timeline for this.

If I have time, I’ll include support for the new experience, but I highly recommend make sure you’re using Native auth as this is far less likely to be affected.

Get the new version here

OnedriveMapper v3.10 released!

Version 3.10 of OneDriveMapper has been released!

  • handle the new tile / prompt that appears in IE login mode where Microsoft no longer always redirects to the portal
  • Progress bar color is now a configurable option (cloud/non cloud)
  • alphabetic ordering of configs (cloud only)
  • Fixed auto update loop issue where auto update would break itself for subsequent updates.
  • When restarting self (switching auth mode or auto updating) properly hide the console if this was set

Important Auto Update Instructions

If you were using Auto-Update, DO NOT do so for this version. Use the MSI to replace the old version (see last fixed issue).

New Azure AD Signin experience

As some may have read, Microsoft is previewing a potentially disruptive change without advance notice. My tenants don’t yet display the new behavior so I cannot test if OnedriveMapper will be affected. I haven’t heard of any issues yet 🙂

Get the new version here

The process cannot access the file ‘C:\Windows\system32\config\systemprofile\AppData\Roaming\Windows Azure Powershell\TokenCache.dat’ because it is being used by another process.

While building some multithreading Azure Runbooks that log into multiple subscriptions simultaneously, I noticed that these multiple concurrent runs often end up on the same Azure Automation Host.

Apparently, these runbooks then don’t run in full isolation, and the following error may occur:

The running command stopped because the preference variable “ErrorActionPreference” or common parameter is set to Stop: The process cannot access the file ‘C:\Windows\system32\config\systemprofile\AppData\Roaming\Windows Azure Powershell\TokenCache.dat’ because it is being used by another process.

AzureProfile.json may also get locked. I resolved this by doing a retry on the Save-AzureRMContext, and using a randomized file name for the azure json profile:


$randomProfileName = [System.IO.Path]::GetRandomFileName()

Save-AzureRmContext -Path .\$randomProfileName -Force -Confirm:$False

And for my full Azure Login code snippet:

$randomProfileName = [System.IO.Path]::GetRandomFileName()
 $tries=0
    while($true){
        $tries++
        try{
            Write-Output "Logging in to Azure $azureSubscription"
            $res = Login-AzureRmAccount -Credential $azureCreds -SubscriptionId $azureSubscription -TenantId $tenantId -ErrorAction Stop
            Select-AzureRmSubscription -SubscriptionId $azureSubscription -ErrorAction Stop -TenantId $tenantId
            if($res.Context.Subscription.Id -eq $azureSubscription){
                Write-Output "Logged in to Azure subscription $($res.Context.Subscription.Id)"
            }else{
                Throw "Failed, we were logged in to $($res.Context.Subscription.Id) while trying to log in to $azureSubscription"
            }
            Save-AzureRmContext -Path .\$randomProfileName -Force -Confirm:$False
            break
        }catch{
            if($tries -ge 30){
                Throw
                Exit
            }
            #sleep on failed attempts, as the azure token cache gets locked by concurrent jobs
            sleep -s (Get-Random -minimum 1 -maximum 6)
        }
    }

Transferring a domain to Azure (dns and billing)

Lately I’ve been playing with custom domains in Azure, Microsoft has been allowing us to directly purchase domain in Azure for a while now. This leverages GoDaddy’s API, but Microsoft bills you for the domain, consolidating your domains, management and usage nicely in Azure.

The portal only allows you to purchase new domains, so how do you transfer existing domains to Azure DNS?

First you’ll need a transfer code, which you can get from your current DNS provider. Then, execute the following script:


Register-AzureRmResourceProvider -ProviderNamespace Microsoft.DomainRegistration
$rgName = "NAME OF YOUR RESOURCE GROUP"
$ResourceLocation = "Global"
$ResourceName = "MYDOMAINNAME.NL"
$PropertiesObject = @{
'Consent' = @{
'AgreementKeys' = @("DNPA","DNTA");
'AgreedBy' = '122.13.11.20'; #ip address you're running this script from
'AgreedAt' = '2017-17-07T08:37:40'; #roughly the current time
};
'authCode' = 'DOMAIN TRANSFER CODE'; #code by current domain provider
'Privacy' = 'true';
'autoRenew' = 'true';
}

New-AzureRmResource -ResourceName $ResourceName -Location $ResourceLocation -PropertyObject $PropertiesObject -ResourceGroupName $rgName -ResourceType Microsoft.DomainRegistration/domains -ApiVersion 2015-02-01 -Verbose

It will take a long time to run, but you’ll have a custom domain in Azure that you can now connect to websites and/or manage through AzureDNS.

Note: this only works for domains OLDER than 60 days and can take 5-7 days until the domain is usable in Azure, all domain records will be copied to an Azure DNS zone.

Exchange 2010 backend with 2013 frontend proxy something has gone wrong error

At a customer site users were experiencing “:-( Something went wrong” errors in OWA (2013). The RPC endpoint was also broken, blocking a migration to Office 365.

Initial checks showed a few errors on the 2013 frontend server:


[Eas] Marking ClientAccess 2010 server NLEX01.domain.local (https://nlex01.domain.local/Microsoft-Server-ActiveSync) as unhealthy due to exception: System.Net.WebException: The remote server returned an error: (503) Server Unavailable.
at System.Net.HttpWebRequest.GetResponse()
at Microsoft.Exchange.HttpProxy.ProtocolPingStrategyBase.Ping(Uri url)

[Autodiscover] Marking ClientAccess 2010 server NLEX01.domain.local (https://nlex01.domain.local/Autodiscover) as unhealthy due to exception: System.Net.WebException: The remote server returned an error: (503) Server Unavailable.
at System.Net.HttpWebRequest.GetResponse()
at Microsoft.Exchange.HttpProxy.ProtocolPingStrategyBase.Ping(Uri url)

[RpcHttp] Marking ClientAccess 2010 server NLEX01.domain.local (https://nlex01.domain.local/rpc/rpcproxy.dll) as unhealthy due to exception: System.Net.WebException: The remote server returned an error: (503) Server Unavailable.
at System.Net.HttpWebRequest.GetResponse()
at Microsoft.Exchange.HttpProxy.ProtocolPingStrategyBase.Ping(Uri url)

[Owa] Marking ClientAccess 2010 server NLEX01.domain.local (https://nlex01.domain.local/owa) as unhealthy due to exception: System.Net.WebException: The remote server returned an error: (503) Server Unavailable.
at System.Net.HttpWebRequest.GetResponse()
at Microsoft.Exchange.HttpProxy.ProtocolPingStrategyBase.Ping(Uri url)

The issue ended up being twofold;

  1. somehow the SCCM client on the Exchange backend had replaced the local server certificate that IIS uses, this certificate wasn’t accepted by the frontend server
  2. for some reason NTLM (Windows) Authentication was switched off on the Virtual Directories on the backend machine.

AADSTS165000 after enabling Modern Auth in Exchange Online

If you enable Modern Auth in Exchange Online with Set-OrganizationConfig -OAuth2ClientProfileEnabled $true , and then start seeing this error in Office 2016 or 2013 clients:

AADSTS165000: Invalid request: the request tokens do not match the user context. One or more of the user context values (cookies; form fields; headers) were incorrect or invalid, these values should not be copied between requests or user sessions; always maintain ALL of the supplied values across a complete single user flow. Failure reasons:[Token is invalid;]

You need to re-activate Office.

Automatically bitlocker Windows 10 MDM Intune Azure AD Joined devices

I recently ran into an article by Pieter Wigleven, based on an original idea of Jan Van Meirvenne that I simply have to share, and expand upon.

When you go cloud first, and do light MDM management of your Azure AD Joined Windows 10 devices, you will likely enable a Bitlocker policy in Intune. What you’ll quickly discover, is that your policy will not automatically enforce/enable Bitlocker on non-InstantGo capable devices.

So, I expanded upon Jan and Pieter’s script to automatically enable Bitlocker on Windows 10; it has additional error handling, local logging and it will eject removable drives prior to immediately (vs reboot) encrypting your system drive. After this is started, it will register your recovery key in AzureAD. Of course all credit for the original idea goes to Jan van Meirvenne.

Powershell source file

enableBitlockerAndRegisterInAAD.ps1 (right click, save as)

MSI file

enableBitlockerAndRegisterInAAD_v0.2.msi(right click, save as)

As Intune won’t let you deploy a Powershell script, I’ve also wrapped the script in an MSI file with Advanced Installer for you. What this will do;

  1. Deploy the PS1 file to the machine
  2. Register a scheduled task to run this PS1 file at logon each time
  3. Kick off the scheduled task once so a first reboot isn’t required

Advanced installer package (.aip)

enableBitlockerAndRegisterInAAD.zip (right click, save as)

Requirements

  1. Windows 10, AzureAD Joined
  2. TPM chip
  3. User should be local admin

O365Migrator v0.99 released!

An import bugfix and two new features:

  • bugfix: if a homedir fails to upload, the document library’s versioning setting would stay disabled
  • if you’re uploading homedirectories, the script will attempt to set the author/editor of all files to the owner of the homedirectory (thanks for the idea Sean!)
  • new ‘unAuthorize’ button, to remove admin permissions from homedirectories after the migration

Get it here