Azure AD and Manual UPN Update

In Azure AD, the UserPrincipalName (UPN) can be manually updated using Set-MsolUserPrincipalName Power Shell cmdlet.  The details and syntax are explained here –

One of the common issues you experience during this process is the “Access Denied”  error message. 

 Set-MsolUserPrincipalName : Access Denied. You do not have permissions to call this cmdlet

If you are using Global Administrator account, you should have permission to update user properties. This error message can be little misleading.  Most of the time, you will see this error message because of an non-existent UPN name in the “-UserPrincipalName” parameter.

Set-MsolUserPrincipalName -UserPrincipalName -NewUserPrincipalName

Here are some examples:

As you can see in the following screenshot, I am getting the Set-MsolUserPrincipalName : Access Denied. You do not have permissions to call this cmdlet message here.  


I am using a Global Administrator account here.  This is because of the non-existent UPN (current UPN of the user from Azure).  If you run Get-MsolUser cmdlet, you will see the real error message 🙂   “Get-MsolUser : User Not Found.  User:” error message. 


You need to verify current Azure UPN before you the Set-MsolUserPrincipalName or you can combine Get-MsolUser and  Set-MsolUserPrincipalName cmdlets to include this validation check to get some more meaningful error message. 

Get-MsolUser -UserPrincipalName | Set-MsolUserPrincipalName -NewUserPrincipalName


Also, make sure to verify the Custom Domain in Azure if you are planning to use a custom domain name as UPN.

image image

Powered by WPeMatico

F5 VPN Plug-in and NPuroamHost.dll Issue

By default, the F5 VPN plug-in (F5 Networks Firepass Host Plugin) doesn’t install from Internet Explorer 11 browser.  If you try the manual installation option, you will get only the NPuroamHost.dll file. Copying and pasting this DLL doesn’t work and also, you won’t be able to find a plug-in directory. 



You can resolve this issue by adding your VPN URL or company URL to Compatibility View Settings in IE.

image image

Powered by WPeMatico

Azure Password Reset – The Password you’ve selected does not meet your Active Directory password policy

This is a common error message when you try to reset a password from Azure management port or Self service portal.  The error message is very clear here – “The Password you’ve selected does not meet your local Active Directory password policy”.   So you have to start with your Active Directory password password policy. 



You also see a detailed information in Event log of your directory synchronization server. 


I have seen many issues related to Minimum Password Age value.  By default, it is 1 day.  If you are trying to change the password again on the same day , you may need to change value to 0.  Anyway, the error message from Azure is directly related to the configuration you have in your AD password policy as shown below: 


Powered by WPeMatico

Azure – Your account is temporarily locked to prevent unauthorized use

Here is the another common error message when dealing with directory and password synchronization. 

Error Message:

Your account is temporarily locked to prevent unauthorized use. Try again later. Contact Customer Support if the problem persists


Make sure the directory synchronization service account has proper permission in AD. Permission details are documented in this article –

The above error message is related to Replicating Directory Changes and Directory Changes All permission in AD. 

From “If you intend to configure password sync to Azure AD, ensure this account has the following permissions assigned: -Replicating Directory Changes  -Replicating Directory Changes All”

Powered by WPeMatico

Verify Service Status Remotely Using Local Account – PowerShell Script

I have modified one of my previously published script – Stop, Start, Disable Service Remotely–PowerShell Script ( to use Local account (instead of a domain account) to verify the status of the service.



Input file contains computer names in the following format:


Powered by WPeMatico

Collect Computer Information From Active Directory– PowerShell Script

This PowerShell script can be used to collect computer information from Active Directory.   I am searching only Windows XP and Windows 7 machines.  You can update these values  by modifying $OS1 and $OS2 variables.

$OS1 =  “Windows 7*”
$OS2 = “Windows XP*”

This script is schedule to run everyday.  That is the reason I have include a backup file location and a file copy process.


$BKlocation = “E:ScriptsWin7Report_Backups”
$Verify = Test-path -PathType Container $BKlocation
If ($Verify -eq $false)
{$Verify = New-Item -ItemType Directory -Path $BKlocation }
move-item “E:ScriptsWin7win*.txt” $BKlocation –Force

I am currently collecting only the following information.  You can add more details based on your requirement.

$tName = $
$tOS = $ItemProp.operatingsystem
$tSP = $ItemProp.operatingsystemservicepack
$tDes = $ItemProp.description
$tLoc = $ItemProp.distinguishedname
$tBuild = $ItemProp.operatingsystemversion




In my case, I am using an input file which contains the Distinguished Name of the OU.  You don’t have to use an input file, if you are searching an entire Domain.  


Powered by WPeMatico

PowerShell – Tips, Tricks and Useful Commands

Tip #4 –





Tip #3 – Comparison Operators

Published date – May12, 2013































.csharpcode, .csharpcode pre
font-size: small;
color: black;
font-family: consolas, “Courier New”, courier, monospace;
background-color: #ffffff;
/*white-space: pre;*/
.csharpcode pre { margin: 0em; }
.csharpcode .rem { color: #008000; }
.csharpcode .kwrd { color: #0000ff; }
.csharpcode .str { color: #006080; }
.csharpcode .op { color: #0000c0; }
.csharpcode .preproc { color: #cc6633; }
.csharpcode .asp { background-color: #ffff00; }
.csharpcode .html { color: #800000; }
.csharpcode .attr { color: #ff0000; }
.csharpcode .alt
background-color: #f4f4f4;
width: 100%;
margin: 0em;
.csharpcode .lnum { color: #606060; }



More info –


#2 Logical Operators
Published date – April 11, 2013


Logical AND


Logical OR


Logical XOR


Not equal to


Not equal to


More info –

#1 Special Characters – Published Date – April 9, 2013

PoweShell supports the following special characters:









Form feed


New line


Carriage return


Horizontal tab


Vertical tab


Stop parsing


More info –

Powered by WPeMatico

PowerShell TTUC #13 – Scheduled Jobs

PowerShell Tips, Tricks and Useful Commands (TTUC) #13 – Scheduled Jobs

PowerShell scripts can be run as a scheduled job using using Windows scheduler.  Create a batch file with the following syntax/commands:


Powershell.exe “c:scriptsmytestscript.ps1”


Powered by WPeMatico

PowerShell TTUC #15 – File Name with Time Stamp

PoweShell TTUC (Tips, Tricks and Useful Commands) #16 – File Name with Time Stamp

File can be created with date / time suffix using the following syntax / commands:

New-item -type file -Name (“MyFile_$(Get-Date -f MM-dd-yyyy_hh-mm-ss).txt”) –force

New-item cmdlet will create a new file.  Get-data cmdlet will append date and time in MM-dd-yyyy_hh-mm-ss format.

Powered by WPeMatico

Extracting Microsoft Azure AD Connection Tool

As you aware, the Azure Directory Sync supports custom installation.  For custom installation and configuration you need to extract the Microsoft Azure AD Connection Tool (MicrosoftAzureADConnectionTool.exe)  installation medial first.  There are few command line options supported as shown in the following screenshot:


To exact the Microsoft Azure AD Connection Tool installation media to a specific folder, you can run the  MicrosoftAzureADConnectionTool.exe /T:C:DirectorySync /C command. All the extracted files will be in the C:DirectorySync  folder.

Powered by WPeMatico

Azure MFA with pGina and Local Authentication

The current Azure MFA doesn’t have a plug-in for local workstation and sever authentication. So I was testing some other scenarios using an open source application called pGina. You can read more information here – .

PGina supports different protocols, for this testing I was using RADIUS . From an MFA perspective, it is same as any other RADIUS and 2FA configuration. Here are some of my notes:

Azure MFA and RADIUS configuration details are well documented in so I am not planning to add any details here. For this testing, I have added my client machines as “Clients” as shown in the following screenshot:


Since I am using domain joined machines,  I have selected Windows Domain as the target. 


Those are the only configuration you need to make on the MFA server. Next step is to configure the PGina application on your workstation – of course it has to be locally installed on the machine.    Open pGina application from the workstation and select the appropriate plug-in. I have selected RADIUS. 


Select Configure button to enter your MFA server information. 


You don’t need to make any other changes unless you are planning to configure multiple authentication and priorities.   From the Simulation tab, you can validate your authentication configuration. Based your MFA configuration (Phone call, Text message, Mobile app, OATH token) the user will receive a second after authentication prompt.   


Since my test account was configured to use MFA Mobile App, I received the following 2FA request on my configured device. 


You will also see the authentication status in the Result section. 


If your MFA server is in Azure or planning to connect it remotely, make sure to open the appropriate ports.  In Azure, additional End Points (port 1812 and 1813) need to be opened for your MFA.

Note: You are enabling public access to your servers.  Understand the risk before making these configuration changes 🙂


You also need to modify pGina client with correct Azure server name or IP address. It is easier to use the Cloud Service name (


Powered by WPeMatico