This script has been developed for a custom project with the following requirements:
The script utilizes a self developed C# command line tool, which has been published as open source at Github. The ResizeImage Wiki explains the usage of the command line tool. The application's configuration controls the target size and an optional pixel based offset.
Maybe the script will be useful in your project as well.
The code samples utilize the following folder structure:
# Resize photos stored in the default PictureSource folder for Exchange On-Premises (648x648) and write images to user mailboxes
# Resize photos stored on a SRV01 share for Exchange Online and save resized photos on a SRV02 share
.\Set-UserPictures.ps1 -ExchangeOnline -PictureSource '\\SRV01\HRShare\Photos' -TargetPathExchange '\\SRV02\ExScripts\Photos'
# Resize photos stored in the default PictureSource folder for Active Directory (96x96) and write images to user thumbnailPhoto attribute
# Resize photos stored in the default PictureSource folder for Intranet (150x150)
Using this script you can test the domain availability in Office 365 and Azure AD. As there are different closed Office 365 and Azure AD regions you need to test per dedicated closed Office 365 region.
Regions currently implemented:
The script queries the login uri for the selected Office 365 region.
The response contains metadata about the domain queried. If the domain already exists in the specified region the metadata contains information if the domain is verified and/or federated.
Load function into your current PowerShell session:
# Test domain availability in the default region - Office 365 Global
Test-DomainAvailability -DomainName example.com
# Test domain availability in Office 365 China
Test-DomainAvailability -DomainName example.com -LookupRegion China
Original source: https://blogs.technet.microsoft.com/tip_of_the_day/2017/02/16/cloud-tip-of-the-day-use-powershell-to-check-domain-availability-for-office-365-and-azure/
It might happen that a mobile device running an Android operating system is not being redirected properly by the on-premises AutoDiscover service, when the mailbox has been migrated to Office 365.
If your device is not redirected, the device prefix is not recognized by Exchange Server and therefore not being redirected properly. The new device redirect feature for Android devices was introduced in Exchange Server 2010 SP3 RU9, Exchange Server 2013 CU8, and Exchange Server 2016.
The following device prefixes are known to Exchange by default:
If the device prefix of your device is not part of the default list, you can add the prefix to the AutoDiscover web.config file.
Add the device prefix to the MobileSyncRedirectBypassClientPrefixes key in the appSettings node.
<add key="LiveIdBasicAuthModule.AllowLiveIDOnlyAuth" value="true" />
<add key="LiveIdBasicAuthModule.ApplicationName" value="Microsoft.Exchange.Autodiscover" />
<add key="LiveIdBasicAuthModule.RecoverableErrorStatus" value="456" />
<add key="LiveIdBasicAuthModule.PasswordExpiredErrorStatus" value="457" />
<add key="ActiveManagerCacheExpirationIntervalSecs" value="5" />
<add key="ProxyRequestTimeOutInMilliSeconds" value="30000" />
<add key="LiveIdNegotiateAuxiliaryModule.AllowLiveIDOnlyAuth" value="true" />
<add key="TrustedClientsForInstanceBasedPerfCounters" value="bes" />
<add key="InstanceBasedPerfCounterTimeWindowInterval" value="900000" />
<add key="MobileSyncRedirectBypassEnabled" value="true" />
<add key="MobileSyncRedirectBypassClientPrefixes" value="Acer,ADR9,Ally,Amazon,Android,ASUS,EasClient,FUJITSU,HTC,HUAWEI,LG,LS,Moto,Mozilla,NEC,Nokia,Palm,PANASONIC,PANTECH,Remoba,Samsung,SEMC,SHARP,SONY-,TOSHIBA,Vortex,VS,ZTE" />
As always: Be careful when modifying application settings. Test such changes in a test environment first, if possible.
You need assistance with your Exchange Server setup? You have questions about your Exchange Server infrastructure and going hybrid? You are interested in what Exchange Server 2016 has to offer for your environment?
Contact me at firstname.lastname@example.org
Follow at https://twitter.com/stensitzki
Troubleshooting Outlook connectivity issues with Office 365 is tricky. Administrators can use two valuable tools provided by Microsoft to identify and even fix client related connectivity issues.
Start with the Outlook account problems test page in the Office 365 portal. You need to log on as the Office 365 user having issues.
The site tests for the following:
If no issues are identified after you've logged on to Office 365, move to the next step.
The Microsoft Support and Recovery Assistant (SARA) for Office 365 is click to run tool that is installed and executed locally.
These two tools fix most of the Outlook connectivity issues you are facing as an Office 365 administrator.
Enjoy Office 365
When you use the Exchange Online Portal to move a cloud mailbox to on-premise (aka Office 365 Offboarding) you can either move
When you select the second option, the move request fails because of the missing archive target delivery domain. The required attribute is not exposed to the Exchange Online Administrative Center.
The required option -ArchiveDomain can only be applied when using Remote PowerShell to Exchange Online.
The following lines describe how to move the primary mailbox to your opn-premise Exchange while keeping the archive mailbox in Office 365:
# UPN of user to migrate to Exchange Online
$User = "UserToMigrate@mcsmemail.de"
# FQDN of configured migration endpoint
$RemoteHost = "MigrationEndpoint.mcsmemail.de"
# on-premise target domain
$TargetDelivery = "mcsmemail.de"
# EOL archive domain
$ArchiveDomain = "TENANT.onmicrosoft.com"
# on-premise target mailbox database name
$TargetDatabase = "MBX-DB01"
# Onpremise credentials to access the target mailbox/on-premise Exchange
$OnPremCred = Get-Credential
# New offboarding move request with automatic completion of the request
New-MoveRequest -Identity $User -RemoteHostName $RemoteHost -RemoteCredential $OnPremCred -TargetDeliveryDomain $TargetDelivery -ArchiveDomain $ArchiveDomain -PrimaryOnly -SuspendWhenReadyToComplete:$false -Outbound -RemoteTargetDatabase $TargetDatabase
Your scripts can go from here.