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

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

Import PSTs into Office 365 via PST Capture

Recently, I needed a somewhat automated way import PST files (gathered from an on premise Exchange 2010 SP3 environment) to mailboxes in Office 365.  Though importing through PowerShell was somewhat appealing, it also was not appealing.  Instructing the users or help desk group to manually import each PST via Outlook drew a similar reaction.  I had heard of Exchange PST Capture but had never used it.  However, it seemed like it would be a much more elegant way of performing bulk PST imports.  Prepping a machine for PST Capture was a chore but once all was set up it worked smoothly.

The biggest challenges with this project were: getting the machine ready for the PST Capture Console, dialing in permissions to import PSTs (both on premise and in Office 365) and locating the Office 365 server.

PST Capture Console…

Requirements for the PST Capture Console weren’t necessarily difficult but they were not anticipated for sure.  We used a VM with Windows 7 Enterprise with SP1 that had a single CPU and 4GB of RAM.  If importing PSTs to an on premise Exchange server, the console requires the Exchange environment to be 2010 or 2013.  And if importing to the cloud, O365 Exchange Online is required.  In general, the console machine requires .NET Framework 4.5, PowerShell 3.0 (which is found in Windows Management Framework 3.0) and the 64-bit version of Outlook 2010 (this is only required on the console and not any other workstations).

Permissions…

I created a “PST Admin” account on premise (with a mailbox) to handle the migration for both internal and cloud-based PST migrations.  On premise, this account need only to have domain user rights by default but must be assigned Organization Management and Public Folder Management along with assigning a new role to allow import/export access of the mailboxes.  To perform this new role assignment, I issued the following command…

New-ManagementRoleAssignment -Role “Mailbox Import Export” -User “PSTAdmin”

Additionally, I provided access for this user the mailbox database by issuing this command…

Get-MailboxDatabase -Identity “Mailbox DB 1” | Add-ADPermission -User “PSTAdmin” -AccessRights GenericAll

With the basic permissions set for importing to an on premise mailbox, I needed to perform a couple of tasks on the PST Capture console machine itself.  First, I assigned the PST Admin account local admin rights to the machine and second created an Outlook profile to access the mailboxes.  If the second is not performed an error will be generated when attempting to import a PST that the destination mailbox is not accessible.

To import PSTs into a mailbox in Office 365, similar permissions need to be set up for accessibility.  In my scenario I used the existing Office 365 tenant admin.  Within the Exchange Admin Center of Office 365, I created a new admin role named “Migration Impersonation” with assigned roles of “ApplicationImpersonation” and “Mailbox Import Export” for the O365 admin.

Import…

To import PSTs into a mailbox in Office 365 we needed to know (or find out) a couple of details.  One is the username and password of the O365 account we will be using to import PSTs and the other is the name of the Office 365 server.  The first is easy.  The second can be a bit of a chore.

Finding Office 365 server name…

With the older version of Office 365, sign into the portal, access the mailbox, click on the question mark then select About.  In the About window, locate the Host Address.  It should look similar to https://bluprd0711.outlook.com/owa which is similar to what is found for the URL in the browser.  For the new version of Office 365 (Wave 15), I have yet to locate the name (host address) like in the previous version however it can be gleaned from the URL.

Once we have this information, open PST Capture (while signed on as PST Admin) to modify the Online Connection settings.  From the toolbar, click Tools > Settings.  The first option is Online Connection Settings.  Enter the O365 username and password.  Make certain that “Grant delegate access to this mailbox” checked.  Next, enter the O365 server name.  Do not include “https://” or anything after outlook.com (e.g. /owa).  Check the box to confirm it is an Office 365 server.  Finally, click “Check”.  This “Check” will validate connectivity to Exchange Online.

To verify the settings are correct, while performing a “Cloud Import” select the link in the Destination Mailbox column.  If all is configured properly a list of mailboxes in Exchange Online should appear.  Select a destination mailbox, click OK and proceed to import.

Caveat…

One big caveat that I discovered is that each machine you would like to scan for PSTs must have .NET Framework 4.5 installed and the PST Capture client.  If you have all PSTs consolidated into a single repository you will only have one machine to worry about.  However, if you have thousands of machines that may potentially have PSTs on them, System Center or group policy will be the best method to install the prerequisite applications.

Conclusion…

I have not documented each step on purpose as I feel it is important to understand the whole process through trial and error not to mention the tasks may vary for each environment.  However, I felt that documenting the biggest challenges I experienced was important.  Additionally, several links are provided below to reference sites used to get this solution up and running.  Hope they help you too.

Happy PST importing.

Reference(s): Exchange PST Capture, Install PST Capture, Hands on with the PST Capture Tool, Configure PST Capture Settings

by Todd Nelson