Wednesday, April 27, 2016

Exchange Hybrid Configuration Wizard fails with error HCW8073: PowerShell failed to invoke Set-EmailAddressPolicy

Exchange Hybrid Configuration Wizard fails with error HCW8073: PowerShell failed to invoke 'Set-EmailAddressPolicy'.
HCW log under "%UserProfile%\AppData\Roaming\Microsoft\Exchange Hybrid Configuration" shows:

*ERROR* [Workflow=Hybrid, Task=Recipient, Phase=Configure] Microsoft.Online.CSE.Hybrid.Engine.TaskException: Task 'Recipient' failed during phase 'Configure': Set-EmailAddressPolicy -Identity 'Default Policy' -ForceUpgrade: $true -IncludedRecipients AllRecipients Errors PowerShell failed to invoke 'Set-EmailAddressPolicy': The recipient policy "Default Policy" with mailbox manager settings cannot be managed by the current version of Exchange Management Console. Please use a management console with the same version as the object. ---> Microsoft.Online.CSE.Hybrid.Engine.WorkflowException: 

HCW8073 PowerShell failed to invoke 'Set-EmailAddressPolicy': The recipient policy "Default Policy" with mailbox manager settings cannot be managed by the current version of Exchange Management Console. Please use a management console with the same version as the object.

When you try to update your address policy according to documentation on your Exchange Server 2010 or Exchange Server 2007:

Get-EmailAddressPolicy | where {$_.RecipientFilterType –eq “Legacy”} | Set-EmailAddressPolicy 
–IncludedRecipients AllRecipients
The recipient policy "Default Policy" with mailbox manager settings cannot be managed by the current version of Exchange
Management Console. Please use a management console with the same version as the object.
    + CategoryInfo          : InvalidOperation: (Default Policy:ADObjectId) [Set-EmailAddressPolicy], InvalidOperation
    + FullyQualifiedErrorId : 7124D31B,Microsoft.Exchange.Management.SystemConfigurationTasks.SetEmailAddressPolicy

This happens when the Default Policy also includes Mailbox Manager settings. Since there are no Exchange 2003 servers anymore (or 2003 console) in this environment, you can’t remove the Mailbox Manager settings from the policy (ex. wrong upgrade procedure from Exchange Server 2003). Additionally you may have warning like this:

Get-EmailAddressPolicy | fl Identity,*type*,*version*,*manager*

Identity                 : Default Policy
RecipientFilterType      : Legacy
ExchangeVersion          : 0.0 (6.5.6500.0)
HasMailboxManagerSetting : True

Here’s how to fix this using ADSI Edit:
  • Run adsiedit.msc
  • In the Configuration container, navigate to CN=Recipient Policies,CN=<Exchange Org>,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=<domain>,DC=<com> 
  • In the middle pane, view the properties of the Default Policy
  • Remove the value(s) of the msExchMailboxManagerFolderSettings attibute so that it’s now <Not Set> 
  • Edit the MsExchPolicyOptionList attribute and remove all the attributes that do not begin with 0xFC. The policy that begins with 0xFC is the email addressing policy.

FC 1C 49 26 50 9E 57 48 86 1B 0C B8 DF 22 B5 D7 = Address List pol
EC 13 68 3B 89 CE BA 42 94 42 D8 7D 4A A3 0D BC = MailBox Manager Policy

Now when you run Get-EmailAddressPolicy “Default Policy” | fl you will see that HasMailboxManagerSetting is set to False and you will be able to update the Default Policy.

[PS] C:\Windows\system32>Get-EmailAddressPolicy | fl Identity,*type*,*version*,*manager*

Identity                 : Default Policy
RecipientFilterType      : Precanned
ExchangeVersion          : 0.1 (8.0.535.0)
HasMailboxManagerSetting : False

MVP blogs
Address List and EAP filter upgrades with Exchange Server 2007

Saturday, April 23, 2016

Password Sync as a Temporary Fall-Back from Federated authentication in Office 365

Authentication is a fundamental part of Office 365. Office 365 and ADFS hybrid deployment scenario with High-Availability (especially with Geo redundancy properties) requires significant deployment effort, resources and etc. In most cases this is not a problem for a large Office 365 customers who have few data-centers, resources to deploy Azure IaaS and ADFS farm there.

The role of ADFS farm is critical in a single site deployment for Small to Middle sized Office 365 customers.
You may have multiple reasons why ADFS farm can be disconnected from Office 365:
- on-premises data-center Internet connection is down
- internal server maintenance that had impact on ADFS servers
- internal network maintenance that had impact on ADFS servers
- expired digital certificate
- etc...

If you cannot pass through federated authentication in services like Exchange Online, Skype for Business Online (which can have PSTN Calling functions enabled with E5) and etc. then you cannot do your business as well.

With such ADFS downtime scenarios one of the options to recover authentication is to switch temporarily from Federated to Synchronized Password Authentication. You should implement "Password synchronization" with AAD Connect sync prior you have outage to the AD FS infrastructure. It has no impact on existing Federated authentication.

Temporarily “Switch” from Federated Authentication to Synchronized Password is not automatic option and requires manual configuration. Federated authentication can be changed to synchronized password authentication on a per-domain basis in the event of an outage to the AD FS infrastructure.
  • Run the Windows Azure Active Directory Module for Windows PowerShell as an Administrator 
  • Run the following commands from the primary AD FS server:
$Cred = Get-Credential

Connect-MsolService –Credential $Cred
Convert-MsolDomainToStandard –DomainName <federated domain name> -SkipUserConversion $true -PasswordFile C:\Temp\passwordfile.txt

# Once the outage is over use the following command to convert the domain back to federated:
Convert-MsolDomainToFederated –DomainName <federated domain name> -SupportMultipleDomains

It is recommended that you do not change UserPrincipalNames or ImmutableIds after converting your domain to the managed state for users that have been switched to use synchronized passwords.

It is worth noting that switching between Federated Authentication and Synchronized Password Authentication for sign in to Office 365 is not instant and will likely interrupt service access. This may not be a factor in the initial activation (as it’s likely an outage scenario) however it is something to bear in mind when cutting services back to Federated Authentication.

Wednesday, April 20, 2016

Create cloud-only contact objects in Exchange Online to represent on-premises dynamic distribution lists

When running in an Exchange Hybrid configuration, DirSync/AADSync takes care of maintaining a consistent Global Address List (GAL) for both on-premises and cloud users. The one exception is with regards to Dynamic Distribution Groups; these objects need special care to ensure that the recipient filters produce the desired results and for the objects to show up in the cloud GAL.

Neither DirSync nor AADSync will synchronize Dynamic Distribution Groups to Windows Azure Active Directory. As a result, Dynamic Distribution Groups located on-premises will not appear in the GAL for Exchange Online users.

To make these groups appear, Microsoft recommends creation of a contact object directly in Exchange Online with the SMTP address of the on-premises dynamic group. Since the contact is created on the cloud side and the dynamic group does not sync, there is no risk of an address conflict. The Exchange Online users can then see the “group” (really represented by a contact) in the GAL and sending a message to it will route on-premises where the group members will be evaluated.

The PowerShell script below will handle creation of the contact objects in Exchange Online for all Dynamic Distribution Groups on-premises. It adds also on-premises legacyExchangeDN as X500 to cloud contact to resolve "Outlook Autocomplete" issue (that you might have after mailbox migration to Exchange Online)

$CloudCredential = Get-Credential
Write-Host "Getting Dynamic Distribution Groups..." -foregroundcolor white
Set-AdServerSettings -ViewEntireForest $True
$DDGs = Get-DynamicDistributionGroup
Write-Host "  Dynamic Distribution Groups Found:" ($DDGs).count -foregroundcolor green

# Connect to Exchange Online with "Cloud" prefix
Write-Host "Connecting To Exchange Online..." -foregroundcolor white
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri -Credential $CloudCredential -Authentication Basic -AllowRedirection -WarningAction SilentlyContinue
Import-PSSession $Session -Prefix Cloud -DisableNameChecking | Out-Null

# Create Contacts in Exchange Online
foreach ($DDG in $DDGs) {
  Write-Host "  Creating Contact Object For:" $DDG.DisplayName.ToString() -foregroundcolor green
  New-CloudMailContact -ExternalEmailAddress $DDG.PrimarySmtpAddress.ToString() -Name $DDG.Name.ToString() -Alias $DDG.Alias.ToString() -DisplayName $DDG.DisplayName.ToString() | Out-Null
  Set-CloudMailContact $DDG.Name -EmailAddresses @{Add=("X500:"+$DDG.LegacyExchangeDn)} -CustomAttribute1 "On-Premises DDG" -RequireSenderAuthenticationEnabled $true

# Disconnect Exchange Online Session
Write-Host "Disconnecting From Exchange Online..." -foregroundcolor white

Friday, April 15, 2016

Exchange Online users cannot see on-premises Exchange Server Free/Busy information


Comes almost each time after Exchange Hybrid Configuration Wizard (HCW) finished its job successfully
  • Customer's Exchange Hybrid configuration based on Exchange Server 2010 (you have all chances to have newer 2013/2016 versions affected).
  • Customer's on-premises users can see Free/Busy status of Exchange Online users in Office 365. 
  • However Exchange Online users can't see status of on-premises Exchange Server users.
  • Hybrid Deployment has passed Free/Busy and Autodiscover tests of Remote Connectivity Analyzer.
  • Hybrid Deployment has passed through "The Hybrid Free Busy Troubleshooter" with no errors until it suggested to open ticket with Microsoft Support team.
  • Following PowerShell command showed no errors:

    Test-FederationTrust -UserIdentity <OnPremisesMailbox> -verbose
  • Following PowerShell command was already showing WSSecurity enabled:

    Get-WebServicesVirtualDirectory -Identity "HybridServer\EWS (default web site)" | fl *auth*

    InternalAuthenticationMethods   : {Basic, Ntlm, WindowsIntegrated, WSSecurity}
    ExternalAuthenticationMethods   : {Basic, Ntlm, WindowsIntegrated, WSSecurity}
    LiveIdSpNegoAuthentication      : False
    WSSecurityAuthentication        : True
    LiveIdBasicAuthentication       : False
    BasicAuthentication             : True
    DigestAuthentication            : False
    WindowsAuthentication           : True

  • However we noticed error "500" in W3SVC IIS logs of Hybrid Exchange Server very similar to:
POST /autodiscover/autodiscover.svc/WSSecurity - 443 - ASAutoDiscover/CrossForest/EmailDomain//15.01.0225.018 – 500 0 0 124

Unknown :)

You'll be surprised... In my case even though "Get-WebServicesVirtualDirectory | fl" showed WSSecurity being enabled the following command fixed issue:

Set-WebServicesVirtualDirectory -Identity "<HybridServer>\EWS (default web site)" -WSSecurityAuthentication $true

Some guys reported they had exactly the same resolution for Autodiscover IIS virtual directory even though "Get-AutodiscoverVirtualDirectory | fl" showed WSSecurity being enabled:

Set-AutodiscoverVirtualDirectory -Identity "<HybridServer>\Autodiscover (Default Web Site)" -WSSecurityAuthentication $true

Some guy reported he has resolved by adding static DNS entries for and into the local hosts file on Hybrid Exchange Server (which were previously non-resolvable on it).

And another one solved it simply with iisreset after initial Hybrid configuration.

I like my solution since it has no services restart and downtime for Exchange Server.


Wednesday, April 6, 2016

Use PowerShell to manage Office 365 Unified Groups

As of today there is no way to accomplish few Office 365 Group management tasks via Office 365 portal UI:
  • add Office 365 Unified Group as a member of a traditional Exchange Online Distribution List;
  • allow users to "Send As" the Office 365 group;
  • add Quota Setting for Office 365 Unified Group Site
However you can still leverage Exchange Online PowerShell to resolve mentioned tasks.

Add the Office 365 Unified Group as a member of classic Exchange Online Distribution List:

Add-DistributionGroupMember -Member

Allow users to "Send As" the Office 365 Unified Group:

Add-RecipientPermission -Identity -Trustee -AccessRights SendAs

Add Quota Setting for the Office 365 Unified Group Site:

Set-SPOSite –Identity https://<tenantname><groupname> -StorageQuota 3000 -StorageQuotaWarningLevel 2000  

Use PowerShell to manage Office 365 Groups

Tuesday, April 5, 2016

Physical network adapter MAC address information - PowerShell Report

You have new or existing network with no or outdated inventory of server-to-switch port connectivity information. Your Network engineer is going to discover server-to-switch port connectivity information remotely using MAC addresses of physical network adapters.
PowerShell script will convert a Windows MAC address to a Cisco friendly MAC address.
Physical network adapter vendors: Intel, Broadcom (acquired by QLogic)

Active Directory domain joined servers based on Windows Server 2012+
Domain account that is member of local administrator group on servers (such as Domain Admin)

PowerShell script
which gathers all MAC addresses of physical network adapters on servers:

$cred Get-Credential
$serverlist = (Import-CSV ServerList.csv).Servers
$Report @()
foreach ($server in $serverlist) {
$CimSession = New-CimSession -Credential $cred -ComputerName $server
Get-NetAdapter -CimSession $CimSession | where {$_.InterfaceDescription -match "broadcom*|intel*|Qlogic*"} | Sort-Object Name | foreach {
$Properties = @{
MACAddress=($_.MacAddress -replace "-","").insert(4,".").insert(9,".").ToLower();
$Report += New-Object PSObject -Property $Properties}
$Report | Export-CSV MACReport.csv -NoTypeInformation

where CSV-file content of ServerList.csv just like: