Alternative “Portal” Access to Office 365 Services

A great post by Sean McNeill reminding us that there are alternative methods to access Office 365 services (Exchange Online, SharePoint Online, Lync Online) in the event of an outage to the primary O365 portal.

http://office365evangelist.com/?p=2007

Todd (@oddytee)

Advertisements

Force Sync to Office 365 with New DirSync

On June 3, the Directory Synchronization tool was updated.  It is now known as the Windows Azure Active Directory Sync tool and is available to Office 365 customers within their portal.

The following is an update to an earlier post, “Force DirSync for Office 365“.

There might be occasion where a change in your on-premise Active Directory will need to be forcibly replicated to your Office 365 account.  Maybe it is for a new user or a change in a user attribute.  In any case, the standard scheduled sync occurs every 3 hours.  However, we have been given the tools to synchronize those changes on our terms.

From your DirSync server, open PowerShell and navigate to C:\Program Files\Windows Azure Active Directory Sync.  Then enter, .\DirSyncConfigShell.psc1.  A new PowerShell console will open.

From this console, type Start-OnlineCoexistenceSync and press enter.  This command will begin a synchronization of the changes made in the on-premise AD to Office 365.  It is the same command that is automatically scheduled to run every 3 hours.

Once the synchronization is complete, the Office 365 Users management portal will show “Last synced less than an hour ago“.  The Application log in the Event Viewer on the DirSync server will show several events.  The primary one to watch for is Directory Synchronization Event ID 114–this shows us the “Export cycle completed. Tracking id: …

Microsoft Forefront Identity Manager (FIM) 2010 R2…

FIM is another way to check if the sync has completed successfully and, maybe even more importantly, check what users and attributes have been synced.  FIM is installed with DirSync.  FIM has a application know as the MIIS client that can be located in C:\Program Files\Windows Azure Active Directory Sync\SYNCBUS\Synchronization Service\UIShell.  In this folder, double-click miisclient.exe to open Forefront Synchronization Service Manager (FSSM).

From the Operations section of FSSM, we can monitor the sync process and granular changes.  In the Export Statistics section (bottom left of window) within Operations, we can see (and even double-click) the adds, updates, renames and deletes.  In the Object Details, granular information can be viewed by selecting the properties of a Distinguished Name.

by Todd Nelson (@oddytee)

Simplify OWA URL for Exchange 2010

Here are several references to simplify the URL for OWA.

Redirecting OWA URLs in Exchange 2010… http://briandesmond.com/blog/redirecting-owa-urls-in-exchange-2010/

Redirect OWA Exchange 2010 & Exchange 2013 – The Cool and Easy Method… http://blogs.msmvps.com/acefekay/2013/04/16/redirect-owa-exchange-2010-exchange-2013-the-cool-and-easy-method/

NOTE: As of 24 Sep 2013, URL redirection for OWA in Exchange 2013 does not work with the above steps or the MS TechNet article. For simplifying the Exchange 2013 OWA, click here.

Simplify the Outlook Web App URL… http://technet.microsoft.com/en-us/library/aa998359(v=exchg.150).aspx

Simplify the Outlook Web Access URL… http://terrytlslau.tls1.cc/2011/04/simplify-outlook-web-access-url.html

Simplify the Outlook Web App URL… http://martijnwestera.blogspot.com/2012/02/simplify-outlook-web-app-url.html

by Todd Nelson (@oddytee)

Room Lists in Exchange 2013

Creating room lists in Exchange 2010 has developed over time into a process that is fairly easy to implement and visually see (Recipient Configuration > Distribution Group).  However, Exchange 2013 is not quite there yet.

It is true with both Exchange 2010 and 2013 you have to create a room list via EMS.

With Exchange 2010, a distribution group can be converted to a room list…

     Set-DistributionGroup -Identity “West Coast Office” -RoomList

However, with Exchange 2013 CU1 (using the same command syntax), a distribution list cannot be converted to a room list…

     Set-DistributionGroup -Identity “East Coast Office” -RoomList

This is the error receive in the 2013 EMS…

Group “domain1.local/Test/East Coast Office” can’t be converted to a room list. Room lists can only have room mailboxes or room lists as members.
“domain1.local/Exchange Users/Test-Admin” is not a room mailbox or a room list.
    + CategoryInfo          : NotSpecified: (domain1.local/Test/East Coast Office:ADObjectId) [Set-DistributionGroup], TaskInvalidOperationException
    + FullyQualifiedErrorId : F25FFBB1,Microsoft.Exchange.Management.RecipientTasks.SetDistributionGroup
    + PSComputerName        : d1-ex13-01.domain1.local

In order to create a room list in Exchange 2013, we have to create a new distribution list as a room list from the very beginning.  Using EMS, we should be able to issue a command similar to the following to create our new room list…

     New-DistributionGroup -Name “East Coast Office” -OrganizationalUnit “domain1.local/Test” -RoomList

Upon successful creation, we will see that the request is completed with the details of the new room list displayed (Name, DisplayName, GroupType, PrimarySmtpAddress).

The biggest difference for me between 2010 and 2013, is that in 2010 we can see the room list (in EMC) after it has been created (or converted).  In 2013 CU1, room lists are not displayed in the EAC under Recipients > Groups–and they are nowhere to be found in the EAC.

But there is a way to confirm they have been created.  Use the following command to display all distribution groups and what type they are…

     Get-DistributionGroup | ft -auto Name, RecipientType, RecipientTypeDetails

Once we have confirmed the new room list has been created we can add members to it.

NOTE: We can only add room mailboxes (or other room lists) to room lists or we will receive an error message similar to this…

     “Only room mailbox or room list can be added into room list”

At this point, make sure you have a room mailbox to add to a room list.  Once you have identified your list of room mailboxes that will be added to your room list, use the following command to add room mailboxes as members of the room list…

     Add-DistributionGroupMember -Identity “East Coast Office” -Member ConfRoomA@domainname.com

Use the same syntax to add other room mailboxes to your room list.

Now that we have created a room list and assigned room mailboxes to it, scheduling conference rooms for a specific location should be easy using the Office Outlook client or Exchange 2013 OWA.

Reference(s): Scheduling Meetings with Room Finder

by Todd Nelson

On-premise Mail Flow Issue After AD FS Decommission

In my lab last week, I decommissioned AD FS and DirSync to bring Exchange back on-premise after a brief period of co-existence.  The only federated user I had for this environment was no longer able to receive mail in to the on-premise mailbox–however I could send as that user.  The inbound SMTP logs all showed the communication but no successful completion of the connection.

I confirmed the TargetAddress attribute was no longer pointing to the onmicrosoft.com address.

The NDR message received looked like this…

     Delivery has failed to these recipients or distribution lists:

     User

     A problem occurred during the delivery of this message. Microsoft Exchange will not try to redeliver this message for you. Please try resending this message later, or provide the following diagnostic text to your system administrator.

     Diagnostic information for administrators:

     Generating server: exchangeserver.domainname.local

     user@domainname.com

     #< #5.4.6> #SMTP#

The local administrator account also has a mailbox and is able to receive external messages without an issue.  And when I checked this mailbox found NDR messages similar to those just below.  Luckily, I set up the administrator mailbox as the postmaster to be able to see this information…

     The following recipient(s) cannot be reached:

           User on 5/13/2013 11:09 AM

                 A configuration error in the e-mail system caused the message to bounce between two servers or to be forwarded between two recipients.  Contact your administrator.

                 <exchangeserver.domainname.local #5.4.6>

I was able to use the information above to trigger a thought, “Eventhough I removed the reference to onmicrosoft.com, maybe the TargetAddress attribute is still not correct”.

That is when I noticed my mistake, I changed to user@domainname.onmicrosoft.com to user@domainname.com and this is the reason the mailbox would not receive emails–from external and internal senders.  The TargetAddress attribute must be cleared if you want mail to flow properly into an on-premise mailbox.  Any value that is set in this field will attempt to send the message out of the environment even when that email address is local to the environment.  Once the TargetAddress attribute was cleared to <Not Set>, mail flow resumed.

by Todd Nelson

Adding a Subdomain to Office 365

The other day I attempted to add a subdomain to an Office 365 account but received an unwelcomed message…

Can’t add domain … support.mydomainname.com is a subdomain of a domain which was added by using the Microsoft Online Services Module for Windows PowerShell. You must also use this tool to add support.mydomainname.com to Microsoft Online Services.

So…I made the attempt to add it via PowerShell.  First, I reviewed my domain (get-msoldomain) and all appeared fine–Status is Verified and Authentication is Federated.

Next, I attempted to add the domain via PowerShell… New-MsolDomain -Name support.mydomainname.com

But received this…

New-MsolDomain : Unable to add this domain. It is a subdomain and its authentication type is different from the authentication type of the root domain. At line:1 char:15 + New-MsolDomain <<<<  -Name support.mydomainname.com     + CategoryInfo: OperationStopped: (:) [New-MsolDomain], MicrosoftOnlineException     + FullyQualifiedErrorId : Microsoft.Online.Administration.Automation.DomainUnexpectedAuthenticationException,Microsoft.Online.Administration.Automation.NewDomain

Finally, I tried this command… New-MsolFederatedDomain -DomainName support.mydomainname.com

And received another error…

New-MsolFederatedDomain : Failed to connect to Active Directory Federation Services 2.0 on the local machine.  Please try running Set-MsolADFSContext before running this command again. At line:1 char:24 + New-MsolFederatedDomain <<<<  -DomainName support.mydomainname.com + CategoryInfo: InvalidOperation: (:) [New-MsolFederatedDomain], FederationException + FullyQualifiedErrorId : InvalidCommandSequenceGeneva,Microsoft.Online.Identity.Federation.Powershell.AddFederatedDomainCommand

I opened a ticket with O365 support to assist with troubleshooting and received a call back to address.  We were able to resolve the issue relatively quickly.  The key to resolving was in the error received in the previous command I issued … “Failed to connect to Active Directory Federation Services 2.0 on the local machine“.  As I was running the commands from the DirSync server or an admin workstation, the “local machine” being referred to in the error wasn’t the correct machine to run the command from.

Being fairly new to AD FS implementations, apparently it is important where you run your commands from when you have AD FS set up.  All that needed to be done was to access Office 365 via PowerShell from the primary AD FS server and run the same command as above…

New-MsolFederatedDomain -DomainName support.mydomainname.com

Once the command was issued from the primary AD FS server, I received the message “Successfully added ‘support.domainname.com’ domain.”  I checked the domain list in my tenant and via PowerShell (get-msoldomain) to confirm the subdomain was present–and federated.

To test, I added the UPN for my subdomain to the on-premise domain, modified a few accounts to reflect the new local UPN account name, forced DirSync, confirmed the O365 account name had changed and successfully logged into the portal with the new UPN account name (via SSO).

FYI…My actual domain name is not “mydomainname.com”.

by Todd Nelson

Disable Expiration of Office 365 Account Password

You might have a rare situation in which you need to maintain a password for a specific Office 365 account or for all accounts.  Other than being a bad security decision and model it can be done.  However, it can only be done when connected to Office 365 via PowerShell.

In the PowerShell console, check the password status of an individual user or all users.

For individual users… Get-MsolUser -UserPrincipalName “O365 Account UPN” | Select PasswordNeverExpires

For all users, use this command… Get-MsolUser | Select UserPrincipalName, PasswordNeverExpires

If the field for “PasswordNeverExpires” is blank (or does not have a value), the account is likely to be an object that is being synchronized from your local Active Directory.  If the “PasswordNeverExpires” field has a value of “False”, then the account password has an expiration set for it.  Our goal is to disable password expiry by setting the value to “True”.

To set the value to true, we will again show examples for an individual and all users.

For individual users… Set-MsolUser -UserPrincipalName “O365 Account UPN” -PasswordNeverExpires $true

For all users… Get-MsolUser | Set-MsolUser -PasswordNeverExpires $true

If for any reason you need to reset password expiry, change the value of the “-PasswordNeverExpires” switch in the two previous commands to “$false”.

Good luck.

Reference(s): Configure user passwords to never expire

by Todd Nelson