Tag: Azure Active Directory

OneDrive and Active Directory: Error Code 0x8004de40

First time experience such error and behaviour, so the situation is that this user has problem getting her OneDrive to work on her desktop, it was her first time setting it up and she receive the above error code after she sign in and authenticate her account.

Capture

Well from Azure AD, it will shows that her login activity for OneDrive is successful, but Azure AD doesn’t shows that her setup was failed. At first I suspect it could be network issue, tested another account it went through the setup successfully. Hence, running PowerShell (Msol), to query the user account information and perform comparison and everything was showing in good condition.

Another thing is that she can successfully use the web based on SharePoint Online and OneDrive online.

As I went through to the Exchange Admin center and notice her email addresses missing a type, that is the SPO. This type of email address is generated once the user is assigned with the Office 365 license with Sharepoint Online and OneDrive online features.

The only resolution to this is to recreate the account. 

  1. Backup mailboxes to PST and files to a local drive or external drive
    • There are many ways to backup
  2. Unassign the user license
  3. Go to Active Directory and disable the account and move it to a unsync Organization Unit
  4. Go to Azure AD Connect Server and perform the sync
  5. Go to Office 365 make sure that the account has been move to deleted users, well you could use PowerShell to query -ReturnDeletedUsers. 
    • Get-MsolUser -UserPrincipalName <username>@domain.com.my -ReturnDeletedUsers
    • Once it is found, then run the remove command, you can use GUI to remove them at the Azure portal “portal.azure.com” 
      • Get-MsolUser -UserPrincipalName <username>@domain.com.my -ReturnDeletedUsers | Remove-MsolUser -RemoveFromRecycleBin -Force
  6. Go back to your Active Directory and recreate the user account, and make sure it is in the sync OU
  7. Run another sync at your Azure AD Connect Server
  8. Go to Office 365 > Active Users > Search for the user and assign the license

 

There are few reasons why this happen, for my case was the old Azure AD Connect server died or corrupted and had to re-provision a new one. Users are some still on Exchange on-premise and some are in cloud, due to budget. Sometime things happen.

Anyway, hope this helps! 

 

Azure Active Directory: Troubleshoot Immutable ID Matching Error “AttributeMustBeUnique”.

Nowadays there are becoming lots of tools to convert objectGUID to immutable ID. However, one of my friend was facing a problem “AttributeMustBeUnique” in the Azure AD Connect (AADC). Mostly the articles that talk about this error “AttributeMustBeUnique“, is asking people to look at the “Deleted User” or Query the duplicate account from Recycle Bin.

For this case, is slight different.

To understand what is he facing,

  1. A user account was created at cloud first.
  2. A user account status is “in cloud” in Office 365 > Active Users
  3. There is no duplicated account in the Recycle Bin
  4. My friend he empty the Immutable ID and replace it with a new Immutable ID that is covert from objectGUID, to match the account in cloud with its account in on-premise
  5. He used a tool to convert the objectGUID to Immutable ID.
  6. Replace the empty Immutable ID with the converted ones and run a full sync from AADC server. However, he was still getting the error.

After checking upon it was the objectGUID that he copied wrongly. Thus, converted the Immutable ID value wasn’t matching the ones that Azure AD detected.

Azure AD Sync error detection able to detect, identify and provide the suppose correct value of Source Anchor (Immutable ID). Every deployment of Azure AD Connect will match the account via source anchor.

04

What is source anchor? In layman term is the Unique ID from cloud.

References:

  1. http://guid-convert.appspot.com/
  2. https://docs.microsoft.com/en-us/azure/active-directory/hybrid/plan-connect-design-concepts

Office 365: Disable Office 365 Group, the year 2019 way

Mockup-Banner2_0209

Yesterday, I discovered that Microsoft has change the way how to disable office 365 group creation from users. You may refer from this Microsoft Docs and it was last updated in September 2019. It seems that it requires a minimum license of Azure AD Premium Plan 1. You may find this plan in your M365 E3 license. Before this, this was the way on how to disable office 365 group creation from users.

Looking through this blog post, on the Azure portal image, and comparing the current one has changed a lot. Now the group settings in the current Azure portal looks like this;

capture.png

As you can see above the Office 365 Groups settings, you can only control users from creating office 365 groups via Access Panel or Azure portals.

This is an Access Panel;

accesspanel

Identify Azure Active Directory Connect in the Environment (Sync Service)

Ever encounter in an environment where IT does not have visibility of the previous IT actions? Frustrating and irritating right? They were unsure whether is sync service running or not or exist or not.

At first, you will go to portal.office.com to find the DirSync Status, but this is where the funny part, there is a DirSync Management and it has resulted or hint that this Office 365 had Synchronization Service. As you can see below, there is no service account and no last directory sync.

aadc01

Next, I went into their Domain controller > Active Directory Users and Computers > Users OU. I was able to locate 2 Synchronize’s Service accounts, that are not disabled. To locate their location (server), double click on the account to launch the properties. At the description attribute or value, you can identify the location (server name).

  • 1 Service account with no indication of this sync service’s server location in the Description Information
    • Able to locate it, it was inside a Window Server 2008 R2
  • 1 Service account with an indication of its location (inside one of the Domain controller, Windows Server 2012 R2)

I access both of these servers, able to capture

  • Sync tool exist
  • Sync service is running (inside the services.msc)
  • No Operation of sync
  • No connectors in the sync service to be found
  • Windows Server 2008 R2 running Microsoft Online Services Directory Synchronize Service version 2013 year
  • Window Server 2012 R2 running Windows Azure Active Directory Service tool version 2014 year

New version Sync tool naming is “Azure Active Directory Sync Service”.

Another round to proof your findings is to run the PowerShell command to get all attributes of the user list in Active Directory on-premises and Azure Active Directory user list. (If you prefer to filter only a few attributes, then it is up to you.)

For Active Directory

#Run this command in domain controller's windows PowerShell

Get-ADUser -Properties * -Filter * | Export-Csv "filename.csv"

Get one of the oldest (before the year of 2013) and an active employee’s objectGUID.

For Azure Active Directory

Requirements:

  1. .NET Framework installed (latest)
  2. Microsoft  Azure Active Directory Module or PowerShell
  3. Windows PowerShell
#Connect to Azure AD service

Connect-MsolService

#Key in your Global admin credential

#Run this get command to get all user list with its attribute

Get-MsolUser | Export-Csv "filename.csv"

Next, you find the same oldest employee’s immutable id value, if there is value means this environment had sync service running before. You could compare the value that is valid and convert the objectGUID to an immutable ID or the other way around, using this converter.

After locating all this, now you can plan your clean up and recommendations. This may take a longer process, due to you need matching and creation.

 

 

Troubleshoot ADFS Token Signing and Decrypting Cutover

I read through many articles and done much research, and I really thought that the AutomaticRolloverCertificate function would take up its work seamlessly but guess what it didn’t. Well, it did generate the new token correct and changing the new token to the Primary and append the changes to Office 365 federation but it wasn’t able to update the changes in Office 365 federation.

I am not sure whether is this got to do with a single domain environment.

*Note:

Commands/PowerShell you can only run from Primary ADFS unless you had run some PowerShell to allow session establish from another computer. (Which is also fine to proceed, as long as you could establish the connection)

Impact:

  1. Federated Users unable to login

aadc01.PNG

 

Actions are taken:

  1. I have checked the event logs
    • Noticed there is an error about Event ID 111 WS-Trust or Value is null unable to perform the update
    • token01
  2. I have query the output via PowerShell from ADFS server
    • Connect-MsolServices
    • Key in Your Office 365 Global Admin credential (the xx@domain.onmicrosoft.com)
    • Get-MsolFederationProperty -DomainName domain.com

Based on the above 2 actions, I have noticed that it didn’t update the federation in Office 365. It was able to append the changes of the new tokens to the Office 365 but it didn’t update.

Next was;

  1. Run the PowerShell command from primary ADFS to force the update of the new token for Office 365

Connect-MsolServices

#enter your onmicrosoft.com global admin credential

Update-MsolFederatedDomain -DomainName domain.com -SupportMultipleDomain

#Check whether the token in office 365 is updated

Get-MsolFederationProperty -DomainName domain.com

2. Then Restart ADFS services, restart from primary ADFS then to the secondary ADFS

3. Retry to access portal.office.com, then you should be able to access

 

I am trying to simplify this situation with PowerShell Scripting…so stay tuned!

References:

  1. http://terenceluk.blogspot.com/2016/05/the-message-one-of-your-on-premises.html
  2. https://piasys.com/blog/microsoft-office-365-adfs-and-signingencrypting-certificates-renewal/
  3. http://jackstromberg.com/2014/11/office-365-renew-your-certificates-on-premise-adfs-alert/

Azure AD: How to permanent or force delete user from recycle bin via GUI?

As you may know Office 365 admin center doesn’t provide the capability to remove/delete deleted user from recycle bin and you may need to run powershell to do it.

Some of the IT admins may find using power shell is not very efficient than GUI. Currently you could perform the remove at Azure active directory.

Steps:

  1. Sign in to https://portal.azure.com
  2. At the side bar, select “Azure Active Directory”

a1

4. Than select “Users”

a2.PNG

5. Select “Deleted Users”

a3

6. Next, select the users that you wish to permanently remove

a4.PNG

Yes, Microsoft default of permanent remove of deleted user’s account is after 30 days.

 

Office 365: Email address with random numbers attached UPN (user123@contoso.onmicrosoft.com)

Why do some of my users have random numbers attach with their UPN? Well the only answer to this question is, duplication occur because you haven’t force delete the old account from Office 365 recycle bin. And by default there is a setting in Azure AD to detect duplication is set to false, so this is another reason that even there are duplication in AD created and a sync has been trigger the duplication will also be sync to the Office 365.

To prevent any duplication in future to be sync to the Office 365, is to set the duplication checking in Azure AD to true. So that any duplication is scan will be rejected to be sync to the Office 365. To resolve the duplication currently having is to delete the account and resync it to Office 365.

*Note: These random numbers in your smtp has no implication or effects to your mailbox/account, but it is only not nice to see it that way. It is up to your choice to do it or not.

*Azure Module Power Shell needed

  1. Open Azure power shell
  2. Type the following command to get the sync feature

Connect-MsolService

Get-MsolDirSyncFeatures

dirsyncfeature

3. Next, enable both of the feature to true

Set-MsolDirSyncFeatures -Feature DuplicateUPNResiliency -Enabled $true

Set-MsolDirSyncFeatures – Feature DuplicateProxyAddressResiliency -Enabled $true

*Note:

Situation 1: If the mailbox is still new, you will only need to delete the account and force delete from the recycle bin, then do a resync 

Situation 2: If user have the mailbox for very long, you have to break the dirsync wait for the account’s status change from “Sync from on premise” to “on cloud“, then from Office 365 you can edit its smtp address but make sure you have your recycle bin clear from the old account. (Yes this is much troublesome than Situation 1)

Step by step for situation 1

  1. Locate the account from Office 356
  2. Unassign the mailbox license
  3. At Active Directory, move the account to a unsync organization unit
  4. At Azure AD Connect, run a manual sync command

Start-ADSyncSyncCycle -PolicyType Delta

5. Make sure the account at Office 365 has gone to the “Deleted User” Category

6. Once the account has been appear in “Deleted User” Office 365, you have to run a command to force deleted from the recycle bin.

7. Open Azure Module PowerShell

8. Type the following command, enter the UPN that you wish to remove from recycle bin

Connect-MsolService

Get-MsolUser -ReturnDeletedUser

Get-MsolUser -ReturnDeletedUser | Remove-MsolUser -UserPrincipalName xxxx@domain.com -RemoveFromRecycleBin -Force

9. After finish remove the account from recycle bin, move back the account from unsync Organization Unit to Sync Organization Unit

10. At Azure AD Connect, run the manual sync command

11. At Office 365, locate the account and assign license

12. You can notice there is no more random numbers found

Step by Step for Situation 2

*Make sure recycle bin is clear from duplication accounts

  1. Open Azure Module PowerShell
  2. Type the following command, enter the UPN that you wish to remove from recycle bin

    Connect-MsolService

    Get-MsolUser -ReturnDeletedUser

    Get-MsolUser -ReturnDeletedUser | Remove-MsolUser -UserPrincipalName xxxx@domain.com -RemoveFromRecycleBin -Force

  3. Open Azure Module Powershell
  4. Type the following command

Connect-MsolService

Set-MsolDirSyncEnabled -EnableDirSync $false

3. You probably have to wait for 24hr to 48hrs for the dirsync to complete progress

4. At Office 365 > Exchange Online > Recipients > Mailbox

5. Search for the account > Double click on it

6. Go to Email Option > select the smtp address to edit

7. Remove the random numbers from the smtp address

8. Save your changes

*Make sure you put this to lab test before trying it out in actual environment, just to get clear understanding what are you doing

 

References:

  1. https://support.office.com/en-us/article/Turn-off-directory-synchronization-for-Office-365-ee5f861e-bd48-4267-83d1-a4ead4b4a00d

Office 365 & Azure Powershell: Why not to use -SearchString pipe to Set function command?

Even though that you type the following command and it return you a single result, and you thought that it would work but it will not work.

Example:

  1. First you try to get the user, and you able to retrieve a result

Get-MsolUser – SearchString “abc”

#Result
Name                     UserPrincipalName
———                     ——————————-

abc                           abc@domain.com

2. After getting the user, you try to pipe it to a Set function. However, you receive an error like below; this error indicates an exception is trigger in Microsoft  backend and prevent such command to proceed.

Get-MsolUser -SearchString “abc” | Set-MsolUserPrincipalName -NewUserPrincipalName “aaa@domain.com”

#Result

Set-MsolUserPrincipalName : Unable to update parameter. Parameter name: IMMUTABLEID.
At line:1 char:44
+ … abc” | Set-MsolUserPrincipalName -NewUserPrincipalName “aaa…
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : OperationStopped: (:) [Set-MsolUserPrincipalName], MicrosoftOnlineException
+ FullyQualifiedErrorId : Microsoft.Online.Administration.Automation.PropertyNotSettableException,Microsoft.Online.Admi
nistration.Automation.SetUserPrincipalName

3. So the correct way to do it is to either

Get-MsolUser -UserPrincipalName “abc@domain.com” | Set-MsolUserPrincipalName -NewPrincipalName “aaa@domain.com”
OR

Set-MsolUserPrincipalName -UserPrincipalName “abc@domain.com” -NewUserPrincipalName “aaa@domain.com”

*Note: Please test it out before you implement

Azure AD Connect (AADC): How to resolve Stopped-extension-dll-exception?

Usually this error will not have any effect to Office 365 Dirsync, but it is indeed annoying to see error in our Azure AD Connect Sync Client Interface. Is best to resolve this error.

There are only 4 possible causes;

  1. AADC is OUTDATED ()
    • Check for AADC version
    • If it is outdated than update it, run the sync again
    • Reference: https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-upgrade-previous-version
  2. AADC’s schema crashes
    • Run the AADC application and restart the schema
    • Reference: https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnectsync-installation-wizard
  3. Azure AD account Sync password is not set to “Password Never Expired”
    • *Note: By default, when you setup AADC this is already turn on
    • If you had turn this feature off,you have to update the password and enable the feature back on.
    • Run Azure PowerShell Module command 
      • Connect-MsolService
      • #Set new password
        Set-MsolUserPassword         -UserPrincipalName “XXXXXXX” -NewPassword “pa$$word“
      • Set-MsolUser -UserPrincipalName "XXXXXXXXX" -PasswordNeverExpires $true
      • Restart the AADC service
      • #After restart runs finish, type this command
Start-ADSyncSyncCycle -PolicyType Initial
  4. Server itself is having problem
    • Restart the server
  5. Permission missing
    • If you enable single sign-on, remember its minimum requirement of the permission rights for service account is domain admin
  6. DNS routing issue
    • If you notice that you are having trouble resolving “login.windows.net” this is due to your DNS settings in your DNS server/AADC server network settings
    • Most likely is DNS server settings, is configure wrongly
    • Try to run nslookup to identify the return result
    • If there is a forwarder in place, remove it.

The above causes are also the steps-by-steps investigation, and to resolve this error it is best to follow the above category and resolving them.

*Note: This error may occurs after few hours and it is best to monitor for 24 hours or 48 hours.

Office 365: Synchronized/Migrated user showing wrong UPN in Office 365

Oh no! I forgot to change/set the user’s UPN correctly before migration! Even a simple job we could get it wrongly. Thus, this will lead you to panic. Well, if you are panic, just take a deep breath.

Usually, such problem we resolve it by breaking/disable the DirSync so that the user’s status change from “Sync from on prem” to “cloud”. So that if we could make the changes at the Office 365, without interrupting the on-prem. However, this kind of solution is troublesome because it takes hours for the DirSync to complete disable and waiting for the user’s status to change. When I mean by hours, depends of the amount of users you have at Office 365. The larger the amount the longer it takes for the time taken for the DirSync to complete disable and for the user’s status to change.

Here are the problems we faced:

  1. Forgot to set the email policy
  2. Forgot how to set email policy
  3. Set the wrong email policy
  4. Highly confident and doesn’t double check
  5. Doesn’t do enough research about preparation of migration

Lucky for me that I have found a way to solve this kind of clumsiness, please refer to the reference given below.

Note: This solution is only for clumsy situation. Don’t put it into your planing of migration, because this will make you feel like a total blockhead in front of your customers. Please do not take it in as a habit.

Reference:

  1. http://www.codenutz.com/office365-changing-the-main-login-name-for-upn-for-a-user-via-powershell/