Dom Pickett’s Blog

How to pull a list of all conference rooms in Exchange Online?

Dom Picket MSFT — Tue, 31 Jul 2018 14:06:29 GMT

To pull the data you will first need to connect to Exchange Online Powershell. Instructions can be found here. Next run these cmdlets to collect all the conference rooms. get-mailbox -ResultSize unlimited |where {$_.recipientTypeDetails -eq "roomMailbox"} This cmdlet below will get the same results above and export the Display name and Primary SMTP address to a text file. get-mailbox -ResultSize unlimited |where {$_.recipientTypeDetails -eq "roomMailbox"} | Ft Displayname,PrimarySmtpAddress > Rooms.txt

How to update MetadataExchangeURI for Federated domains using SAMLP Protocol

Dom Picket MSFT — Tue, 09 Jan 2018 12:07:48 GMT

Recently I ran into an issue with a customer attempting to update their MetadataExchangeURI for their Federation settings, however when running the necessary cmdlets they noticed the MetadataExchangeURI would not update. As a result this was preventing the admin from completing the setup for federating their domain. You may run into this issue if you are trying to federate your domain using a third-party IDP for federation such as PingFederate, Okta, Centrify, Shibboleth, etc.

We did some testing today, and we found that we had to set the domain back to managed in order to get the MetadataExchangeURI to update. The cause appears to be that even though the MetadataExchangeURI is updated in Microsoft’s MSODS system, it still returns the old value in Microsoft's OrgID system. OrgID does not successfully update the value because when the protocol is set to SAMLP, no updates to the MetadataExchangeURI are allowed. OrgID is a legacy authentication platform first used with live accounts. It is no longer servicing authentication but has not yet been completely decoupled from AAD. As a result this type of inconsistency between the two services will cause issues. Thus we ran some additional test, and subsequently found a workaround to update the MetadataExchangeURI as WSFed, then change the domain to managed, and federate again with the correct values using SAMLP.

Steps to resolve are as follows:

First, Set your values to what you want it to be using a variable.

$domainName = "Davengers.us"

$BrandName = "ADFS"

$browserSSOLoginURL = "https://adfs.davengers.us/adfs/services/trust/2005/usernamemixed"

$logoutURL = "https://adfs.davengers.us/adfs/ls/"

$issuerProviderID = "davengers.us/adfs/services/trust/"

$idpSigningCert = "[insert cert info]"

$MetadataURL = "https://newvalue/adfs/services/trust/mex"

$ssoProtocol = "SAMLP"

Steps to resolve are as follows:

Open Windows Azure Active Directory PowerShell and connect to the MSOL service.
1. Connect-msolservice
Confirm if the domain is currently set to managed or federated.
1. Get-MsolDomain
Set the domain back to managed.
1. Set-MsolDomainAuthentication -DomainName $domainame -Authentication Managed
Federate the domain as WSFed, with the correct URL’s.
1. Set-MsolDomainAuthentication -DomainName $domainName -FederationBrandName $BrandName -Authentication Federated -PassiveLogOnUri $browserSSOLoginURL -SigningCertificate $idpSigningCert -IssuerUri $issuerProviderID -LogOffUri $logoutURL -PreferredAuthenticationProtocol WSFed -MetadataExchangeUri $MetadataURL
Set the domain back to managed. There may be a 1-2 minute replication if you get an error.
1. Set-MsolDomainAuthentication -DomainName $domainName -Authentication Managed
Federate the domain as SAMLP with all the correct URL’s.
1. Set-MsolDomainAuthentication -DomainName $domainName -FederationBrandName $BrandName -Authentication Federated -PassiveLogOnUri $browserSSOLoginURL -SigningCertificate $idpSigningCert -IssuerUri $issuerProviderID -LogOffUri $logoutURL -PreferredAuthenticationProtocol SAMLP -MetadataExchangeUri $MetadataURL
View the results and confirm everything is set as expected.
1. Get-MsolDomainFederationSettings -domainName $domainName | FL

Thanks to Dragos C. and John K. For assistance in writing and editing the article.

Alias in the cloud not synced with On Premises

Dom Picket MSFT — Sun, 04 Jun 2017 19:38:30 GMT

Hello All, Here is another random issue. A user's alias on premise is not synced with the alias in the cloud. You try to run a few delta syncs, and even a full sync but the alias wont sync up. You can't update the cloud object using Set-mailbox or Set-msoluser, so what is next? Well lets first start with what happened. Thus far, I have ran into two possible causes here. First, when the user account was provisioned, the alias that was on premise was invalid. Perhaps an extra space, or a period at the beginning or end of the mailnickname attribute on premise. For the mailnickname attribute, it cannot start or end with a period, as well as must be a unique value. If it is not a unique value, AAD Connect will still sync the user object however it was manually update the attribute to allow the user object to successfully sync. As of result of O365 creating the mailnickname attribute itself, O365 is now the originating authority for the attribute. Therefore subsequent syncs from AAD will not look to sync this attribute. The second source for this may be an administrative change. For example, a colleague knows about the Set-AzureAD cmdlets and manually updated the object in the cloud. Now another admin has the task of fixing the attribute but doesn’t know how. An admin can use this to update both synced with AD or cloud only objects. Nevertheless when you use this cmdlet for an object synced with OnPremise, you are changing the originating authority of the attribute. This means O365 owns the authority of this attribute as opposed to your on premise AD server, thus will not look to sync the attribute in subsequent syncs, unless the attribute itself is specifically changed. The best way to resolve this issue depends on where the user account exist. If the broken account is a cloud only account then you can simply use the Set-AzureADuser cmdlet to update the mailnickname attribute. If the object is syncing from an AD account on premise, then you will need to physically update the alias on premise to force AD Connect to pick up the change and sync that to the cloud. Next go back and update the object again, and force the final sync to the cloud. First we will go through the steps for the quick method. You can use a Set-AzureADuser cmdlet to update the object in the cloud. Steps 1 through 7 goes through the necessary steps to upgrade your Powershell application, and import the necessary modules to run the appropriate cmdlets.

Open Powershell as an administrator
You will need to be running the lastest powershell version which is 5.1.
1. Type this cmd in powershell to determine your current version. $PSVersionTable.PSVersion
2. Click this link to upgrade.
  1. connect.microsoft.com/site1164/Downloads/DownloadDetails.aspx?DownloadID=59185
  2. You may need to install WMF 5.0 to install the new powershell versions. The Prereqs are here. You may need to install WMF 5.0 to install the new powershell versions. The Prereqs are here. https://msdn.microsoft.com/powershell/gallery/readme

Install the Azure AD Module
1. Install-Module -name AzureAD

Import-Module AzureAD

Connect-AzureAD

[Enter O365 admin credentials]

Run this cmdlet to get the information for the AzureAD user. This will show you when the "alias" is currently set to. The attribute used for "alias", is mailnickname.

Get-AzureADUser -SearchString user@domain.com | fl userprincipalname,mailnickname,objectID

Run this cmdlet to update the user with the new desired mailnickname attribute.
1. Set-AzureADuser objectID [insert objected] -mailnickname [enter new mail nick name].

In the event the user object is synced from on premise Active Directory, then the easiest way to resolve the issue is to update the mailnickname object on premise and sync that to the cloud. For example if the user's alias was Sarahjo, change her alias on premise to SarahJo1. This will force AD connect to recognize the attribute change, and upon the next sync cycle the user is O365 will have an alias of Sarahjo1. Now your on premise servers are the source of authority for the attribute again, and we can go back on premise and change to alias to what you want it to be. Update the object on premise again and run a final delta sync to sync the correct alias to O365. Follow steps 8-13.

Update the mailnickname attribute on premise. For example if its set to “Sarahjo”, change it to “Sarahjo1”.
Run an Ad Sync cycle to sync the change to O365.

Start-ADSyncSyncCycle -PolicyType delta

Run the cmdlet from step 3 above to verify the mailnickname attribute changed.
Change the mailnickname to what you want it to be, I.e. “Sarahjo”
Run another Sync cycle to sync to O365.

Start-ADSyncSyncCycle -PolicyType delta

Confirm issue is resolved.

More Information: I am not a scripting expert, but here are a few one liners that may help you get things moving. Use this cmdlet to collect an output of on premise AD users and their current mailnickname attribute. Get-ADUser -Filter * -Properties mailnickname | Sort-Object -Property mailnickname -Descending | ft name,mailnickname,UserPrincipalName > ADusers.log This can be used to collect a list of O365 Azure AD users mailnicknames. You may be able to expand the results, however I have not been able to find a solution to get Get-AzureADUser -Top 500000 | ft UserPrincipalName,mailnickname

How to find Dirsync/AAD Connect Server?

Dom Picket MSFT — Mon, 23 Jan 2017 18:53:37 GMT

Hello All, I recently ran into an issue where an administrator had left the company, and unfortunately he was the only one to know which server was the dirsync server. Prior to beginning this task of restarting the Dirsync service, we discovered that no one knew which server was running Dirsync. This particular admin had over 72 servers that they were responsible for, so rather than going through each server to look for the program or the sync service, I found another trick to find the server running dirsync. All you need to do is go in to the Active Directory Users and Computers and find the MSOL account. In the description of the account it will list which server to which the application was ran.

Open Active Directory Users and Computers.
Search for the account "Msol".
Open the description. The description will tell you where AAD Connect was installed. Scroll to the right, or copy and paste the entire description in a notepad.

Turn off O365 licenses for all users

Dom Picket MSFT — Fri, 09 Dec 2016 17:33:33 GMT

Hello All, If you need to turn off O365 licenses for all users currently using an Office 365 E3, E5 subscription plan or etc, you can go through the following steps to disable some plans that you do not wish for them to use. For example, if you want to assign O365 to all your users, but your not comfortable deploying Yammer yet, you can disable the Yammer subscription for all users at once. Another scenario is if Microsoft enables new features in your tenant such as Flow, Microsoft Teams, or Dynamics, you can follow the steps below to remove them from all users. *Note: Do not run these steps if all your users do not have the same licenses applied. For example if you have some users using Skype for Business but not all of your E3 users are, this will not work for you. The cmdlet below will make changes for All users with that license pack subscribed.*

Get your license account SKU.
1. Get-msolaccountSku
Collect a list of users with a license and place them in a variable.
1. $AllLicensed = Get-MsolUser -All | where {$_.isLicensed -eq $true}
Verify your list.
1. $AllLicensed
Get a list of license currently assigned and disabled for your users.
1. (Get-MsolUser -UserPrincipalName user@domain.com).Licenses[0].ServiceStatus
Create a variable of the subscriptions with the disabled plans. Insert the Sku from step2, and replace Domain:enterpisepack with your exact subscription name. Be sure to leave the quotes. If your licenses are named differently you can get the accurate names from step 5.
1. $LO = New-MsolLicenseOptions -AccountSkuId "[Domain:EnterprisePack]" -DisabledPlans "FLOW_O365_P2", "POWERAPPS_O365_P2", "TEAMS1"
Run the script to update the plans. This script will count out each user in progress.
1. $AllLicensed | foreach {$i; get-msoluser -userprincipalname $_.userprincipalname | Set-MsolUserLicense -LicenseOptions $LO; $i++}
Verify plans have changed. Spot check for a few users, or you can customize a script to output everyone to a CSV.
1. (Get-MsolUser -UserPrincipalName user@domain.com).Licenses[0].ServiceStatus

If you follow the steps correctly, the plans should be disabled for your users. I do recommend testing the new features, as Stream and Teams seem to be nice new features that I use, however I can understand that for security reasons, these need to be investigated prior to releasing to your employees. -Dom

Sharepoint Contact preventing on premise object from syncing to O365

Dom Picket MSFT — Wed, 23 Nov 2016 10:29:24 GMT

Symptom: Mail Contact created via Sharepoint is preventing on premise object from Syncing to O365. Users are creating mail contacts via sharepoint. When the customer attempts to dirsync the user to O365 we get an error that the proxy address already exist in Azure. We checked MSOL and do not see a mail contact, or MSOL user. Need to verify if there is an SPO object that may be preventing the sync.

Cause: This issue occurs due to a constraint in Azure AD that prevents two objects from having the same Proxy Address. This is to ensure all objects are identified by a unique address. To help find the object, you can run this cmdlet: Get-msoluser -searchstring [name]

Resolution:Currently there are no ways to work around this constraint and the Exchange Contact will not sync while the SharePoint Online external users exists in the tenant. The only option is to delete the SharePoint Online external user from the tenant, which will allow the Exchange Contact to sync. Once that is done, you can re-invite the external user which will succeed because SharePoint will detect the conflict and not set the proxy address. The downside to this however is that the External User in SharePoint Online will not have a valid email address set automatically, and must be set in the user profile manually. Microsoft is currently working on a long term fix which will allow an external user to appear in the Exchange address list and we used as a SharePoint external user.

O365 User Photos Not Updating

Dom Picket MSFT — Fri, 09 Sep 2016 16:16:00 GMT

A lot of customers have had questions about user photos. Why are my user photos not syncing to O365? The changes replicate in on premise AD, but why can my cloud users not see the changes? Well, there is an answer for that…

There has been a significant change in how user photos are presented with newer Microsoft services which includes O365. Up until Lync 2010, user photos would use the Thumbnailphoto attribute in Active Directory to sync user GAL photos. In Lync 2013, Exchange Online and Sharepoint Online user photos are stored on the root of the user mailbox. This change was implemented for several reasons, including allowing the ability to allow high resolution photos. In short, the photos are essentially stored in two places.

In Office 365 there are 3 Active Directory systems, Azure AD (the portal) Exchange Online AD(EXO) and SharePoint Online AD (SPO). When you sync a user into Office 365, you sync uploads to Azure AD. From there the user will sync to EXO and SPO accordingly based on licenses assigned. For the user photo attribute Office 365 stores that photo at the root of the EXO mailbox. So for picture sync to work at a user is required to have a EXO license and mailbox. From there the picture will be synched into SPO.

Now SharePoint needs to create 3 thumbnails (S,M,L) to be used in various areas of the product based on photo size requirements. These photos are created and stored on the My Site Host site collection. In order for these files to be created, users must navigate to the About Me page. So even if the picture sync process between Exchange Online and SharePoint Online has completed successfully, the photo will not display in SharePoint until the thumbnail photos have been created. It is also good to note in some cases it may take up to 72 hours before the user photo may show up in Sharepoint Online.

Going forward, for Hybrid Deployments, I advise to set the users photos in the cloud. You can expect the photos to sync to O365 only 1 time from on-premise AD via the thumbnail attribute, after that there is no guarantee the photos will sync. It is best to use the Set-Userphoto cmdlet up update the O365 object. Updating the thumbnail photo on premise and syncing the changes to O365 will update on premise, however EXO does not look on premise at that attribute for changes again.

In order to get the user photos in Exchange Online to work, we will need to store the users photo in the root of the Exchange Online Mailbox. The best way to accomplish this is by using the Set-Userphoto cmdlet like below.

Set-UserPhoto "Paul Cannon" –PictureData ([System.IO.File]::ReadAllBytes("C:\Users\Administrator\Desktop\PaulCannon.jpg"))

If you are having issues with a user photo to need to reset it, It is best to use the Remove-Userphoto, then Set-Userphoto cmdlet again.

If you wish to prevent end users from having the ability to change their user photos it is best to do this via a User Role Assignment Policy in your exchange Admin Center. Uncheck the option in the default role assignment policy (Or other policy applied to your users), for "My PersonalInformation". It is recommended to remove the ability in Exchange, because doing so in Sharepoint will cause replication issues when it tries to sync to EXO.

Uploading photos using the Set-Userphoto cmdlet, I recommend using this cmdlet below to create your session. The difference is using the "Proxymethod=RPS". Using this proxy method, you can upload larger files up to 4MB. For testing purposes I have uploaded a file as large as 4MB. Generally Microsoft recommends keeping the file size under 500KB, because the bigger the file the more space it takes, and the longer it takes to upload.

$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/?proxyMethod=RPS -Credential (Get-Credential) -Authentication Basic -AllowRedirection

If you are still having issues syncing your user photos, I advise to open up a case with Microsoft's Exchange Online team. Good Luck!!

Resources:

https://technet.microsoft.com/en-us/library/jj218694(v=exchg.150).aspx https://support.microsoft.com/en-us/kb/3062745 https://support.microsoft.com/en-us/help/3062745/user-photos-aren-t-synced-from-the-on-premises-environment-to-exchange-online-in-a-hybrid-deployment

Exchange Online Dual Mailbox Issue. I have a mailbox on-premise and Exchange Online for the same user

Dom Picket MSFT — Tue, 14 Jun 2016 15:15:23 GMT

Sometimes things happen. Migration failed, interns assigning a license to a user when their mailbox is on premise, or some other kind of administrative mistake. Now you realize you have a mailbox on premise and a mailbox in O365. In order to fix the problem, you have to remove one of the accounts. The easiest fix is to remove the cloud account and migrate the on premise account. The reason you want to keep the on premise account is mainly for successful authentication, redirects, and mailflow. Below are the steps to accomplish the task of successfully removing and resyncing the user's account. This process will save the current mailbox data in a soft deleted state, removed the MSOL account in O365, resync the AD account on prem to O365 and re-create the mailbox. You know you are running into this issue if you run Get-mailbox in Exchange Powershell on-premise, and you run Get-mailbox in Exchange Online Powershell and both outputs are showing a user mailbox. This is essentially what will need to be done. In Powershell connected to Exchange Online, please run the following steps:

Back up SharePoint and OneDrive data! Once the Msol object is deleted, that data may or may not be recoverable. Need to open a case or reach out to the SharePoint Online team to confirm.
Check to see if the current mailbox for Steve is on litigation hold. If not, Set the mailbox on litigation hold to save the data.
1. Set-Mailbox [insert alias] -LitigationHoldEnabled $true
Verify the litigation hold is in place. *May take up to 60 minutes, but is typically pretty quick.
1. Get-Mailbox [insert alias] | fl *lit*
Get more the mailbox information. We will need the GUID for later.
1. Get-Mailbox [inser alias | fl userpprincipalname,guid
Get-msol user information of the account that we need to purge.
1. Get-msoluser -userprincipalname [insert upn of user] | fl
Delete the old MSOL account information using the objectID from step 4. (Yes, you need to run both cmdlets here)
1. Remove-msoluser -objectid
2. Remove-msoluser -objectid -removefromrecyclebin

Verify the user has been deleted.
1. Get-msoluser -objectid -returndeletedusers
Run Dirsync. The Old account should be gone from delete items. You may need to run Dirsync twice. Verify that the new account has synced to O365 and is showing “Sync with Active Directory” in the O365 admin portal.
Migrate on premise mailbox to EXO.
Assign a license to the new mailbox.
In Exchange Online Powershell, get the mailbox information for the new mailbox. Copy the GUID.
1. Get-Mailbox [user alias] | fl name,GUID
Now merge the data to the new mailbox.
1. New-mailboxrestoreRequest -sourcemailbox [Guid of old mailbox from Step4] -targetmailbox [GUID of new mailbox step 11] -allowLegacyDNMismatch
Verify the mailbox restore is in place.
1. Get-mailboxrestorerequest
Verify the data is restored and the mailbox is healthy.
You can now remove litigation hold for the old mailbox if you chose. If you don’t then the mailbox will just be retained for the length of the specified litigation hold.

Reply to this thread if you have questions or concerns.

Unable to Migrate user to Exchange Online. User not showing in Migration tool.

Dom Picket MSFT — Wed, 11 May 2016 13:15:29 GMT

Hey Guys,

You are attempting to migrate a user to Exchange Online, but when you open the admin console and search for the user, the user is not in the list. This occurs because O365 already has a mailbox for this user. When assigning a license to an object in MSO, it provisioned a user mailbox. Since a Cloud mailbox was provisioned, the user now has dual mailboxes. This means there is a mailbox on premise still and a mailbox in Exchange Online. Dual mailboxes are not advised to have when dealing with O365 because it could cause proxy lookup issues, or users will complain that they are not getting all their emails. In order to resolve this issue, we have to delete the new cloud object and migrate the on premise object to O365. Here are the steps to do so.

In Exchange Online Powershell verify the recipient type. If user mailbox, then you need to remove the mailbox.
1. Get-recipient [alias]
Go On premise to see what the recipient type is as well. Run the same cmdlet as step 1.
If verified that we have 2 different mailboxes, then we need to purge the cloud mailbox since it is new and has no data. Please be sure that the user is not using OneDrive or Sharepoint, if so this data will need to be backed up prior to deleting the msol account. After deleting the MSOL account the OneDrive and Sharepoint data will be gone.
Next Get the External Directory Object ID from the O365 mailbox.
1. Get-Mailbox [alias] |fl *external*
Verify the msoluser account.
1. Get-msoluser -objectid [inset external object ID from step 4]
Remove the msol account
1. Remove-msoluser -ObjectID [insert object ID from step 4]
Purge the msol user account
1. Remove-Msoluser -objectID [insert objectID from step 4] -removefromrecyclebin
Verify the object is gone.
1. Run the same cmdlet from Step 5.
Initiate a Dirsync Cycle
Go back to the O365 portal, verify a new object has been created.
1. Or you can run Get-msoluser -userprincipalname [Insert upn] | fl … You will see a new object ID.
Next go back in the Exchange Admin Center and migrate the user account.

How to get a list of Shared mailboxes and users with permissions to those mailboxes in Exchange Online?

Dom Picket MSFT — Fri, 29 Apr 2016 18:02:43 GMT

Blog Moving Here... Hello All, This is a quick blog post to assist admins with working on resource mailboxes. This post was written specifically for Exchange Online, however it should work for Exchange 2013 and Exchange 2010 as well. In the event that you are trying to pull all the shared mailboxes in your organization and determine who has permissions to what. Follow the cmdlets below and you will be able to export the data to a txt file for you to reference and review at your leisure.

1. The first cmdlet will collect all the shared mailboxes and insert them into a variable.
  1. $Mailboxes = Get-Mailbox -RecipientTypeDetails SharedMailbox -ResultSize:Unlimited | Select Identity,Alias,DisplayName | sort displayname
2. This step will take that variable of mailboxes, and for each one output the name of the mailbox, user with access and the access rights assigned, and write it to a txt file.
  1. $mailboxes | sort displayname | foreach {Get-MailboxPermission -Identity $_.alias | ft identity,user,accessrights} >SharedPermissions.txt

You may notice that you have nested Security groups with permissions to those shared mailboxes. To get the membership list of the nested SG's, the cmdlet will be similar with a few small changes:

Change the enumeration limit to -1 so we can return the full output.
1. $FormatEnumerationLimit =-1
Get the full list Security Groups and add it to a variable.
1. $sgroup= Get-Group -RecipientTypeDetails MailUniversalSecurityGroup -resultsize unlimited
Run a powershell cmdlet so that For Each group we output the displayname and members to a text file named "Group members.txt".
1. $sgroup | sort displayname | foreach {Get-Group -Identity $_.WindowsEmailAddress | fl displayname,members} > SGroupMembers.txt

Note* Line 3 may fail if you are attempting to write to your C directory. You may need to change the directory to write to a temp folder. To change the directory use this cmdlet. This will write the file to your C:\temp folder, if one does not exist. It will be created. CD C:\temp Then run step 3 again. You can do the same with other resource mailboxes such as room mailboxes, shared mailboxes, Universal Distribution Groups, and Universal Security Groups, all you will need to do is change the -RecipienttypeDetails and verify the parameters that you are looking for. Good Luck!