Non-routable UserPrincipalName and Office 365

If your on-premises AD accounts are having UserPrincipalName from non-routable domain like company.local it will prevent you from using ADFS as authentication method to Office 365. It will also prevent you from using Password Sync feature of DirSync. It is because you can’t add and validate company.local domain in Office 365 tenant. Therefore when you synchronize accounts using DirSync that have @company.local set as UPN suffix they will have @tenantname.onmicrosoft.com  as UPN created in Windows Azure Active Directory. So even though passwords will be synced for these accounts, logins will not match.

Reklamy

Global Administrator Office 365 group

When you add user to Office 365 Global Administrator group it will be granted following permissions:

Exchange Online: Organization Management (via TenantAdmins_xxxx)

Lync Online: Lync Online Admin

Sharepoint Onlne: Sharepoint Online Admin

RIM: BBCS Global Admin

You can add administrator account to Global Administrator with powershell using Windows Azure Active Directory Module:
Add-MsolRoleMember -RoleName „Company Administrator” -RoleMemberObjectId 09ac8f78-e9db-4fab-bfb2-c2ee0153835f

„Company Administrator” Role is repesentant of „Global Administrator” group.

You can’t use the domain because it’s not an accepted domain for your organization

After migrating Public Folders from on-premises to the cloud you might want to change Primary SMTP addresses on mail-enabled public folders because they will be set to: @tenant.onmicrosoft.com. However if there is SMTP address present on mail-enabled PF from a domain that is not among Accepted Domains in the cloud, changing of the address will fail with following error:

„You can’t use the domain  because it’s not an accepted domain for your organization”.

Resolution is to remove SMTP address from the object that is not present in Accepted Domains and then edit SMTP addresses.

The same problem may touch editing email address in the Exchange Online for other recipient types.

Two OWA virtual directories on single Exchange 2013 CAS

IF you want to create to virtual diretories for OWA one with FBA, the other one with Windows Authentication remember about coping OWA folder that is located „C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\” and pasting it in the same folder. Then rename it to for example owaInternal

Then run

New-OWAVirtualDirectory –WebSite FBA –Role ClientAccess –Server E2K13 –InternalURL https://mail.ppa.lab/owa -ExternalURL https://mail.ppa.lab/owa -Path „C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owaInternal

Before off course new web site with proper bindings and proper certificate needs to be created:

cd c:\windows\system32\inetsrv

Run to create new web site:

appcmd add site /name:FBA /physicalPath:”%SystemDrive%\inetpub\wwwroot-fba” /bindings:http/<another_IP_Address>:80:

Add HTTPS binding for the FBA web site

appcmd set site „/site.name:FBA” “/+bindings.[protocol=’https’,bindingInformation='<another_IP_address>:443:’]”

Assign certificate using these steps:

import-module WebAdministration

push-location IIS:\SslBindings

get-item cert:\localMachine\my\<Cert Thumbprint>  | new-item <Another_IP_Address>!443

Single Sign On using TMG for Exchange 2013 and Exchange 2007 mixed enviroment

Even though Exchange 2013 RTM CU2 does SSO for OWA between Exchange 2013 and Exchange 2007 you might want to do pre-authentication on TMG or ISA. Then configuration of OWA vdirs and TMG/ISA should be following:

Configure OWA virtual directories for Basic (or NTLM) authentication only:

Set-owaVirtualDirectory „ppa-e2k7srv1\owa (Default web site)” -BasicAuthentication:$true -FormsAuthentication $false

Set-owaVirtualDirectory „ppa-e2k13srv1\owa (Default web site)” -BasicAuthentication:$true -FormsAuthentication $false

Create single Listener with SSO enabled. In authentication Tab of the listener set HTML Form Authentication (Windows Authentication).

Both legacy, and primary namespace should resolve to the same IP n external DNS.

Create two publishing rules:

  • Exchange 2013 OWA publishing  rule (use Exchange 2010 wizard) with Authentication Delegation set to Basic (or NTLM depending on OWA vdir auth on Exchange)
  • Exchange 2007 OWA publishing  rule with Authentication Delegation set to Basic (or NTLM depending on OWA vdir auth on Exchange)

Single Sign-On to OWA in Office 365 using on-premises AD credentials

I had hard time configuring single sign-on to Exchange Online OWA using on-premises AD credentials from domain joined machine. In my configuration there was no Hybrid Configuration yet. Only ADFS and DirSync (no ADFS Proxy as well). When entering https://outlook.com/owa/mydomain.com URL I was redirected to ADFS server for logon (because my domain was configured as Federated Domain in Office 365) but there was Windows Authentication pop-up asking me for credentials.

The problem was caused by the fact that I added my ADFS URL to Trusted Sites in web browser setting not to Local Intranet. After adding https://fs.mydomain.com to Local Intranet sites single sign-on to Exchange Online OWA started to work. I could also resolve it by editing Trusted Sites security settings and allowing User Authentication\Logon\Allow logon with current user name and password.

Cross Forest mailbox move failing: ” Object reference not set to an instance of an object”

In my lab I was testing Cross Forest mailbox between Exchange 2010 and Exchange 2013. I was getting following error when running: New-MoveRequest command:

The call to net.tcp://pawpex01.pawpazure.lab/Microsoft.Exchange.MailboxReplicationService pawpex01.pawpazure.lab (15.0.620.24 caps:3F)’ failed. Error
details: Object reference not set to an instance of an object..
    + CategoryInfo          : NotSpecified: (:) [New-MoveRequest], CommunicationErrorTransientException
    + FullyQualifiedErrorId : 868B0060,Microsoft.Exchange.Management.RecipientTasks.NewMoveRequest
    + PSComputerName        : pawpex01.pawpazure.lab

It was caused by certificate installed on Exchange 2010, that wasn’t trusted by Exchange 2013 server. Export of root CA from Exchange 2010 and import on Exchange 2013 resolved the problem.

Exchange 2013 had already good certificate installed that Exchange 2010 was trusting.

%d blogerów lubi to: