Outlook's Credential Prompts when access exchange online archives

Have you ever encountered a frustrating issue while trying to access your in Outlook, where you are prompted to enter your credentials repeatedly? My team faced this issue recently across multiple Exchange online users, and it caused a lot of disruptions to work. After researching the problem, this issue occurs due to a specific Autodiscover call for the Archive Mailbox, which is going to the 'Root Domain.'

A third-party server answers the 'Root Domain' call, and it should not be returning a 401 for Autodiscover calls. This caused Outlook to believe that it needed to authenticate, and as a result, it ended up prompting me after the cached credentials failed.

We analyzed the problem by collecting data from my Outlook Advanced Logs and Fiddler Traces. This showed that the Root Domain call was causing the issue and that it was an expected Outlook behavior.

Next, I deployed the 'ExcludeHttpsRootDomain' Registry Key on a machine. This prevented the Basic Auth looking prompt and allowed Outlook to avoid the Root Domain call altogether. After relaunching Outlook, the issue was resolved, and the Autodiscover calls for the Primary and Archive mailboxes were successful.

Microsoft later recognized the issue being caused for multiple customers and suggested the fix we deployed was correct. In conclusion, if you are facing a similar issue with Outlook credential prompts for archive mailboxes, you can follow this multi-step process to resolve it. Start by analyzing the problem and collecting data from your Outlook Advanced Logs and Fiddler Traces.

Issue Some users are having issues with Credential Prompts for Archive Mailboxes in Outlook Analysis - We collected data from an affected user including Outlook Advanced Logs and Fiddler Traces - This showed us the prompting is coming from specific Autodiscover calls for the Archive Mailbox which is going to the ‘Root Domain’: POST https://<Domain here>/autodiscover/autodiscover.xml 401 Authorization Required (text/html) - The Root Domain call is answered by a 3rd party server and should not be returning a 401 for Autodiscover calls: Server: IdeaWebServer/5.1.0 - Since the server is retuning a 401 instead of a 500 or other hard failure, Outlook believes it needs to authenticate and ends up prompting after the cached credentials all fail - This ‘Root Domain’ call is By Design Outlook behavior - This Authentication Failure state is due to the Basic Authentication prompt which prevents proper Authentication using Modern Authentication for all subsequent connections, not just the Autodiscover call - Outlook shows a ‘Need Password’ indicator at the bottom of the screen and clicking this allows Modern Authentication to proceed again - That resolves the disconnected state, and the Primary and Archive connections succeed as expected - We deployed the ‘ExcludeHttpsRootDomain’ Registry Key on the affected client machine, relaunched Outlook and the issue was resolved: https://learn.microsoft.com/en-us/outlook/troubleshoot/profiles-and-accounts/unexpected-autodiscover-behavior - This prevented the Basic Auth prompting and allowed Outlook to avoid the Root Domain call altogether as it is not expected to succeed on this environment - A Fiddler trace after the change showed us the Autodiscover calls for the Primary and Archive mailboxes were then successful and no issue with the connectivity

Read More

Azure AD Connect Profile Sequence

What are the steps involved if you have many AD DS environments configured to sync via AAD Connect (of MIM for that matter) and you need to run just one of them manually?

Run the profiles in the below sequence:

Delta Import - AD

Delta Import  - WAAD

Delta Sync  - AD

Delta Sync - WAAD

Export - WAAD

Export - AD

Read More

Check if a computer is part of a domain or not (and which Active Directory Domain)

One of the quickest way of checking if a computer you are on is Workgroup joined or domain joined for admins is by Going to the Settings > System > About > Advanced System Settings> Computer Name 

Alternatively, you can also do a right click on the My Computer folder > Properties > Advanced.

A quicker way of getting to the information (while also finding more helpful information about the computers is to use Get-ComputerInfo cmdlet. You can use it like:

Get-ComputerInfo | select *domain*

For personal machines (not joined to any domains) it will show up under the csdomain as WORKGROUP and CsPartOfDomain as FALSE

For domain joined machines, these parameters will show the name of the domain it is joined to. Also, you can note which type of the server it is (e.g. Memberserver, DomainController, PimaryDomainController etc.) under the CsDomainRole

Read More

How to Force Active Directory replication between Domain Controllers

By Default, the domain controllers in an Active Directory Domain sync ~15 minutes. The time to finish the replication itself may be as short as a few seconds to several minutes depending on the size of the Forest, Number of Domain Controllers, their physical location, and the type of connectivity between the sites. 

Sometimes, you make a change in one of the DCs and then have to wait for it to synchronize to other domain controllers. If you don't want to wait for long, how do you force the sync to see the change replicate immediately in all your DCs, or the particular DC you are on?  

There is a cool & nifty cmdline utility called REPADMIN which can be your friend. It lets you do an on-demand sync of AD objects to, and from your domain controllers. It is the same utility that we often use to detect and troubleshoot AD replication issues in your environments. Here's how you can use it. 

The tool is quite rich and has many ways of use. You can supply the right parameter and flags to do a variety of actions. I'd show you how to use it to do an on-demand sync to or from DCs in two modes: Pull and Push.

#1 PULL Mode i.e. A change made in another DC needs to sync to this DC (where the cmd is run) 

Open elevated CMD or PowerShell i.e. Run as Administrator on your DC and run the following: 

Repadmin /syncall /AeD

This cmdlet will Pull the changes it detects on other available DCs to the DC where its run. Pull is the AD's default way of syncing. 

The output should look similar. 

# 2 PUSH Mode i.e. A change made on your DC (where the cmd is run) and want to immediately push it to other DCs

Open elevated CMD or PowerShell i.e. Run as Administrator on your DC and run the following: 

Repadmin /syncall /APeD

In the above cmdlet, A, e, D and P are flags you specify to the repadmin utility. 

A = All Partitions

e = Enterprise (Cross Site)

D = Identify servers by distinguished name in messages.

P = Push

There are more flags you can read from this Microsoft page. 

Read More

How to Export Microsoft 365 users to CSV by domains via PowerShell

This one is simple, yet something comes my way occasionally. So here's the simplest way of identifying all users using a domains in your Azure AD Tenant / Microsoft 365. 

You can get a report of all users using a domain using the below cmdlets. You will be prompted to specify the domain name when you run. Repeat the script if you have to search multiple domains.

 

 # Find Users by domain (includes search in proxy addresses)

Connect-msolservice

$domainname = read-host "Enter the domain name to get users for"

$domain_users= Get-Msoluser -DomainName $domainname -all| Where-Object { $_.UserPrincipalName -like "*$domainname"}

Write-host "Found $($domain_users.count) users in this domain."

$domain_users | select DisplayName,FirstName,LastName,UsageLocation,UserPrincipalName,Islicensed,@{L = "ProxyAddresses"; E = { $_.ProxyAddresses -join ";"}} | Export-csv .\MSOL_Users.csv -notypeinformation -Append

 

# Find Users by domain (UPN only)

Connect-msolservice

$domainname = read-host "Enter the domain name to get users for"

$domain_users= Get-Msoluser -DomainName $domainname -all| Where-Object { $_.UserPrincipalName -like "*$domainname"}

Write-host "Found $($domain_users.count) users in this domain."

$domain_users | select DisplayName,FirstName,LastName,UsageLocation,UserPrincipalName,Islicensed,@{L = "ProxyAddresses"; E = { $_.ProxyAddresses -join ";"}} | Export-csv .\MSOL_Users-UPN-only.csv -notypeinformation -Append

 

Read More

Bulk update ProxyAddresses in AD using UserPrincipalName | Set-Aduser

A colleague asked for help in updating proxy addresses for multiple users in the local AD. Easy to guess, PowerShell was the answer for bulk changes. Challenge was they only had UPNs or UserPrincipalName and ProxyAddresses available with them which made it slightly non-standard. 

Typically, the scripts you run in the AD use 'sAMAccountName' to identify the users uniquely. They didn't have it. And we did not want to run multiple other processes to get sAMAccountName for all the UPNs. 

On a side note, it is quite a straight-forward task to update attributes for multiple users in the Active Directory using PowerShell. Most attributes can be manipulated easily, however updating ProxyAddresses can be a challenge. This is because it is a multi-valued attribute capable of holding different values.

So, is it possible to update ProxyAddresses for users in bulk using PowerShell with starting with just the UPNs? Yes - just follow the below mentioned steps. If you already have a list of users and the proxy addresses you want to set for them, go straight to step 4. :)

# Step 1: Get a list of users to change. Save the file as C:\Temp\UserList.csv

# Checking Preview of the CSV File in PowerShell

Set-Location C:\temp

Import-Csv UserList.csv 

# Step 2: Check current ProxyAddresses - GET ONLY (Optional step) | Save CSV

Import-Csv UserList.csv | ForEach {

  Get-ADUser -Filter "UserPrincipalName -eq '$($_.UserPrincipalName)'" -Properties SamAccountNAme, ProxyAddresses, UserPrincipalName `

  | Select-Object UserPrincipalName, SamAccountNAme, @{L = "ProxyAddresses"; E = { $_.ProxyAddresses -join ";"}} `

  | Export-Csv -Path C:\Temp\CurrentProxyAddresses.csv -NoTypeInformation -Append

  } 

# Step 3: Edit the exported file with desired changes to the CSV file. Save it as "BulkUpdateProxyAddresses.csv" Use Notepad or Excel to edit it.

# Step 4: See preview of the new file 

Import-Csv BulkUpdateProxyAddresses.csv 

# Step 5: Set ProxyAddresses according to file - REPLACE Mode

Import-Csv BulkUpdateProxyAddresses.csv | ForEach {

Get-ADUser -Filter "UserPrincipalName -eq '$($_.UserPrincipalName)'" -Properties SamAccountNAme, ProxyAddresses, UserPrincipalName `

  | Set-ADUser -Replace @{ProxyAddresses= $($_.ProxyAddresses -split ";") } `

  }

# Step 6: Finally, see the change in local AD and or cmdlet used in step 2 (Remember to use a different filename this time e.g. CurrentProxyAddresses-UPDATED.csv  )

Import-Csv UserList.csv | ForEach {

  Get-ADUser -Filter "UserPrincipalName -eq '$($_.UserPrincipalName)'" -Properties SamAccountNAme, ProxyAddresses, UserPrincipalName `

  | Select-Object UserPrincipalName, SamAccountNAme, @{L = "ProxyAddresses"; E = { $_.ProxyAddresses -join ";"}} `

  | Export-Csv -Path C:\Temp\CurrentProxyAddresses-UPDATED.csv -NoTypeInformation -Append

  } 

Great job! Now verify the changes are visible in the local AD.

Read More

How to change UPNs in Active Directory and Office 365 in bulk with PowerShell Script

What is UserPrincipalName?

The UserPrincipalName attribute value is the Azure AD username for the user accounts.

A UPN consists of a UPN prefix (the user account name) and a UPN suffix (a DNS domain name). The prefix is joined with the suffix using the "@" symbol.

For example, "someone@example.com". A UPN must be unique among all security principal objects within a directory forest.

The UPN is used by Azure AD to allow users to sign-in. The UPN that a user can use, depends on whether the domain has been verified. If the domain has been verified, then a user with that suffix will be allowed to sign-in to Azure AD.

Important:

UPN in Azure AD is unique across the Azure AD Tenant and no two users can have the same UPN.

UPN for the users syncs only once via directory sync process (MIM and Azure AD Connect). Subsequent changes to UPN attribute for any users must be repeated in the Azure AD / Office 365 separately via GUI or PowerShell.

How to find UPNs for users in Office 365?

To get a list of the users with their UPNs, you can connect to Office 365 via PowerShell using M365 admin accounts and run the following cmdlets.

Import-Module MSONLINE

Connect-MSOLSERVICE

Get-msoluser -All | Select-Object DisplayName, FirstName, LastName, UsageLocation, UserPrincipalName, UserType, @{L = "ProxyAddresses"; E = { $_.ProxyAddresses -join ";"}} | Export-Csv -Path E:\Temp\MSOL_Users_25OCT2021.csv -NoTypeInformation

The script generates the following output file ‘E:\Temp\MSOL_Users_25OCT202.csv’. The cmdlets assume ‘E:\Temp\’ directory exists, and the user has ‘write’ access to the location. You can change this path to suit your preferences.

To check a single user, just run one simple cmdlet (after connecting to PowerShell):

Get-msoluser -UserPrincipalName <username> | Select-Object DisplayName, FirstName, LastName, PreferredLanguage, UsageLocation, UserPrincipalName

How to Change UPN for users

Changing UPN for users synced from the local AD is a two-step process. Changes done to UPN in the local AD cannot be synced automatically to the cloud via directory synchronization services like Microsoft Identity Manager or Azure AD Connect.

1. Change the UPN in the local AD
2. Change the UPN in the Azure AD

Step 1: Change the UPN in the local AD

Changing UPN in the Local AD is can be done from AD management tools such as Active Directory Administration Center, Active Directory Users and Computers (dsa.msc) or ADSI Edit.

Changing Single user:

To change a single user, update the AD attribute via the GUI tools or PowerShell.

To change multiple uses at once, PowerShell is recommended.

·     Note: Following the change in the local AD, continue to step 2 to make change in the Azure AD too. If the users you are changing are ‘in-cloud’, skip directly to step 2.

Changing multiple users (in bulk): There are multiple methods are doing this in bulk. Two have been included for this guide.

Method 1: By CSV file

1.      Prepare CSV file of users in the below format. Save the file as ‘Change-UPN-AD-Users.csv’. You can use any other file name. Just remember to use it in the next step if you change it.
Example CSV format:

SamAccountName	NewUserprincipalname
sandeep.verma	Sandeep.verma.NEWUPN@domain.com

 

2.  Type the following and hit enter when completed:

Import-Module ActiveDirectory

Import-Csv .\Change-UPN-AD-Users.csv | foreach-object {
Write-host “Changing UPN for user $($_.SamAccountName) to $($_.NewUserPrincipalName)” -Foregroundcolor Cyan

Set-ADUser -identity $_.SamAccountName -userprincipalname $_.Newuserprincipalname }

3.   Verify by GUI or PowerShell.

Import-Csv .\Change-UPN-AD-Users.csv | foreach-object {Get-ADUser -identity $_.SamAccountName | Select SamAccountName, UserPrincipalName

Method 2: By OU

You can also make changes to UPNs at OU level i.e. all users in the OU you select will get changed to a new domain name you specify. For example, all users un the test OU ‘TestOU’ have ‘vermasandeep.local’ as the UPN suffix and need to be changed to the UPN suffix ‘vermasandeep.in’.

1.      Open PowerShell ISE with appropriate admin permissions.

2.      Type the following and hit enter when completed (change $ou and $server as your OU and Server names):

Import-Module ActiveDirectory

$oldSuffix = "vermasandeep.local"

$newSuffix = "vermasandeep.in"

$ou = "OU = TestOU, DC=VERMASANDEEP, DC=local"

$server = "DCM1"

Get-ADUser -SearchBase $ou -filter * | ForEach-Object {

$newUpn = $_.UserPrincipalName.Replace($oldSuffix,$newSuffix)

$_ | Set-ADUser -server $server -UserPrincipalName $newUpn

}

Note: $oldSuffix represents the old domain UPN suffix. $newSuffix represents the new UPN suffix. $ou represents the search path in which and IT professional can use a specific OU or an entire domain.

3.      Verify by GUI or PowerShell.

$ou = "OU=TestOU,DC=VERMASANDEEP,DC=local"

Get-ADUser -SearchBase $ou -filter * | Select SamAccountName, UserPrincipalName

 

 Step 2: Change the UPN in the Azure AD

To change a single user’s UPN in the Azure AD, you can use the following cmdet.

Import-Module MSONLINE

Connect-MSOLSERVICE

Set-MsolUserPrincipalName -UserPrincipalName <Current UPN> -NewUserPrincipalName <New UPN>

For bulk changes, below mentioned PowerShell script is recommended.

1.      Prepare CSV file of users in the below format. Save the file as ‘Change-UPN-AzureAD-Users.csv’. You can use any other file name. Just remember to use it in the next step if you change it.
Example CSV format:

SamAccountName	NewUserprincipalName
sandeep.verma	Sandeep.verma.NEWUPN@domain.com

 

2.     Type the following and hit enter when completed:

        Import-Module MSONLINE

 Connect-MSOLSERVICE

 Import-Csv .\Change-UPN-AzureAD-Users.csv | foreach-object {

Write-host “Changing UPN for user $($_.UserPrincipalName) to $($_.NewUserPrincipalName)” -Foregroundcolor Cyan

Set-MsolUserPrincipalName -UserPrincipalName $_.UserPrincipalName -NewUserPrincipalName $_.NewUserPrincipalName }

3. Verify by GUI or PowerShell.

Import-Csv .\Change-UPN-AD-Users.csv | foreach-object {Get-ADUser -identity $_.SamAccountName | Select SamAccountName, UserPrincipalName

 

Note:

If you try changing the UPN from a managed domain to a federated domain, the following error will appear.

Set-MsolUserPrincipalName : You must provide a required property: Parameter name: FederatedUser.SourceAnchor

If you have such a scenario, leave a comment for help.

Checking results

Once the script above has been run successfully, use the following PowerShell cmdlets to check the new UPNs.

Import-Module MSONLINE

Connect-MSOLSERVICE

Get-msoluser -All | Select-Object DisplayName, FirstName, LastName, UsageLocation, UserPrincipalName, UserType, @{L = "ProxyAddresses"; E = { $_.ProxyAddresses -join ";"}} | Export-Csv -Path E:\Temp\MSOL_Users_25OCT2021.csv -NoTypeInformation

 

Read More

Skype for Business Online PowerShell connections are blocked

Issue: 

You as a Global Admin or Skype for business Admin or Teams Administrator cannot connect to Skype for Business PowerShell Module. The Error that appears is as follows:

New-PSSession : [admin0a.online.lync.com] Processing data from remote server admin0a.online.lync.com failed with the

following error message: Skype for Business Online PowerShell connections are blocked.

Cause

Microsoft has discontinued the Skype for Business Online PowerShell module and you cannot download the old powershell module anymore. If you have the module already installed on your machine and you try to connect to the service, you get the above mentioned error. 

Teams administrator were notified through Message center post (MC244740, dated March 16, 2021; MC250940, dated April 16 2021) about this change.

Solution

You can update the Microsoft Teams PowerShell on the machine and use it to connect the online service using PowerShell.

# Open PowerShell as an Administrator, and use update-module cmdlet. 

Update-Module MicrosoftTeams 

Once Updated, you can connect to Microsoft Teams using the Connect-MicrosoftTeams Cmdlet

Connect-MicrosoftTeams

Read More

Add members to Teams without Welcome Messages

When you add someone to Teams, the recipients get a welcome message by Microsoft. In some situations, you might to suppress this default behavior by changing the setting at the Teams level.  

To DISABLE the welcome message, just use this parameter on the individual Teams or Unified Group " UnifiedGroupWelcomeMessageEnable"

You'd need to be connected to Exchange Online module via PowerShell for it to work.

Set-UnifiedGroup -Identity "Name of your Team or Group" -UnifiedGroupWelcomeMessageEnable:$false

Example - 

Set-UnifiedGroup -Identity "TEST Team1" -UnifiedGroupWelcomeMessageEnable:$false

If you want to restore the welcome email functionality, just set it to $True again.

Example: 

Set-UnifiedGroup -Identity "TEST Team1" -UnifiedGroupWelcomeMessageEnable:$true

Read More

ADFS Error 1297, Event ID 7000, Event ID 352 The Active Directory Federation Services service failed to start due to the following error: A privilege that the service requires to function properly does not exist in the service account configuration

Issue

The Active Directory Federation Services service failed to start due to the following error and cannot be started with the following error -

Windows Could not start the Active Directory Federation Services on Local Computer. 

Error 1297: A privilege that the service requires to function properly does not exist in the service account configuration. You may use the Services Microsoft Management Console (MMC) snap-in (services.msc) and the Local Security Settings MMC snap-in (secpol.msc) to view the service configuration and the account configuration.

In the event viewer, this may accompany the Event ID 7000, Event ID 220 and Event ID 352.

Cause

This can be caused after installation of Security Patches or Windows Updates on the ADFS Server, change of  ADFS Service Account, changed permissions to the service account in the local computer or in the Active Directory, Changes to Group Policy etc.

Solution

Check if the ADFS Service account has Generate Security Audits Permission on the local Computer. 

• On Run Type "Gpedit.msc" or launch Local Group Policies MMC Console.
• Go to Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> User Rights Assignment.
• From Right Pane, Select Generate security audits.
  
  
  
• Add your ADFS Service Account here.
  
  
  
• Exit Local Group Policies MMC Console.
• Open Command Prompt "CMD" and type "GPUPDATE /FORCE"
• Set the ADFS Service to Run as the ADFS Service Account.
  
  

• Restart ADFS Service
  
  
  
  
  
  

Happy Single Sign-On!

Read More