Office 365

Office 365: Errors during cutover migration

This is an error I’ve received when running a cut-over migration batch in Office 365.

  1. Error: ProvisioningFailedException: The parameters passed to the cmdlet represent a managed account, which doesn‎’t match the namespace state, which is federated.

I’ve reached out to support, to help me troubleshoot this.  So far there hasn’t been much I’ve been able to find online regarding my situation.

More to be shared as soon as I have additional information.

Update – 02/04/2015

With the idea that this may have something do with our domain being federated as we had already setup a ADFS server when we were configured for Hybrid.

So let’s recap on the Error: ProvisioningFailedException: The parameters passed to the cmdlet represent a managed account, which doesn’t match the namespace state, which is federated.

Focusing on the message above I was able to find do some research to research based on some blog searches that indicated the issue was with our federation status.
I ran the following command from our ADFS Server: Get-MsolDomain

Results:

I had also reviewed the setting using Get-MsolDomainFederationSettings followd by the federation properties with Get-MsolFederationProperty

Using the Get-MsolDomain I was able to identify that the domain for jermsmit.com was verified and also had a federated authentication status.

I change this back to Managed by running the following command:

This was verified by running the Get-MsolDomain to check my results.  And that worked.

I then moved forward by deleting the current failed batch; which took some time.  Once deleted, created a new batch.  At this time the cut-over migration sync is working

 

– Jermal

Notes:  To run the commands in this post you need connect the active directory power shell to your office 365 account – http://jermsmit.com/azure-active-directory-module-for-windows-powershell-how-to-connect/

 

How to Remove Users From the Office 365

The time may come to clean up. Here are steps I have taken

To delete the account for one or more users

  1. Sign in to Office 365 with your work or school account.
  2. Go to the Office 365 admin center.
  3. Go to Users > Active Users.
  4. Choose the names of the users that you want to delete, and then select DELETE Delete.
  5. In the confirmation box, select Yes.

Done; not so fast.  The deleted users is not fully gone yet. It takes 30 days after you have deleted the user for it to purge from Office 365.  However there is a way to do this faster

To delete, deleted users in Office 365

Connect to Exchange Online using the Windows Azure Powershell module.

To connect you enter the following cmdlet’s:

This will prompt you for your credentials and stores them within $msolcred.

Next we enter to connect using the stored credentials

Now that you are connected you can issue the following command to list deleted users

Display deleted user

To remove the deleted user

If you had multiple users, this method would work to remove all deleted users recycle bin

 

Remove Dead Exchange Servers from Active Directory

Working with  my Exchange 2012 Hybrid configuration I into the following error:

ERROR : Subtask NeedsConfiguration execution failed: Configure MRS Proxy Settings

Execution of the Get-WebServicesVirtualDirectory cmdlet has thrown an exception. This may indicate invalid parameters in your hybrid configuration settings.

The task wasn’t able to connect to IIS on the server ‘exchange’. Make sure that the server exists and can be reached from this computer: The RPC server is unavailable.

This is because I did not properly remove the retired exchange servers form Active Directory during past migrations to Exchange 2013.

To remove these objects to continue with your Hybrid configuration task do the following:

  1. Launch the run dialog (Windows Key + R)
  2. Type in the command “adsiedit.msc” and press OK
  3. In the drop down menu select “Configuration”
  4. Expand “CN=Configuration [domain]\CN=Services\CN=Microsoft Exchange\CN=[organization]\CN=Administrative Groups\CN=Servers”
  5. Right click on the dead server and “Delete”
  6. Navigate to ”CN=Configuration [domain]\CN=Services\CN=Microsoft Exchange\CN=[organization]\CN=Administrative Groups\CN=Databases”
  7. Right click on each dead database and “Delete”

Step 1-5 will get you past the Hybrid error, but you might as well cleanup while your here.

Cumulative Update 6 for Exchange Server 2013

I’ve been working with the Microsoft team on several issues I have faced with my Exchange Hybrid deployment.

Most recent issue: HCW Serialization Error

Today I am informed that Cumulative Update 6 for Exchange Server 2013 was just released.

Cumulative Update 6 for Microsoft Exchange Server 2013 was released on August 26, 2014. This cumulative update resolves a list of issues.

Source:  http://support.microsoft.com/kb/2961810

Download Here

 

Error: Subtask CheckPrereqs execution failed: Check Tenant Prerequisites

I needed to make a change to our Hybrid configuration when the following issue was encountered: Subtask CheckPrereqs execution failed: Check Tenant Prerequisites

After multiple attempts to run this and troubleshooting. I find out that the issue was caused by recent changes to Exchange Online.

The first KB informed me to remove an invalid certificate
KB2772596 – http://support.microsoft.com/kb/2772596

The issue still existed after after the removal, I later found the following: KB2988229 – http://support.microsoft.com/kb/2988229

Its time to run a cumulative update (CU). In my case I will need to be at Cumulative Update 5 for Exchange Server 2013 (KB2936880)

If you are unsure what version of exchange you are currently running you can use the following Exchange Powershell Command:

Get-ExchangeServer | Format-List Name, Edition, AdminDisplayVersion

Here is a table for reference below

Product name Release date Build number
Exchange Server 2013 CU5 May 27, 2014 15.00.0913.022
Exchange Server 2013 SP1 February 25, 2014 15.00.0847.032
Exchange Server 2013 CU3 November 25, 2013 15.00.0775.038
Exchange Server 2013 CU2 July 9, 2013 15.00.0712.024
Exchange Server 2013 CU1 April 2, 2013 15.00.0620.029
(RTM) Exchange Server 2013 December 3, 2012 15.00.0516.032

 

 

 

The Truth – Single Sign On with Outlook and Office 365

After many twists and turns on this bumpy road of setting up a Hybrid Deployment of Exchange Online with AD Sync and ADFS for SSO.  I am faced with yet another issue.

Let me tell you what does work with the single sign on:

  • Outlook via Web Access
  • Office 365 Portal
  • Office 365 SharePoint
  • Office 365 Yammer
  • Office 365 Web Apps
  • Office 365 Lync Online

For the most part any Office 365 web services offered using a web browser, as long as its Internet Explorer.

Missing from the above list of working items is Outlook! That’s right; Outlook doesn’t work.

In fact; users of Outlook will be prompted to enter their credentials on first use.  Let me break right here and describe first use.

First use is any time you open Outlook, you will be prompt for a password to log in.  Unless you save it.

In addition to having to save your password locally in the Windows Credential Manager, you will need to update this password which was saved each and every time you change your password.

This is not my understanding of what the term “Single Sign On” was to be. Good job to Microsoft’s Office 365 Marketing Team.  You had/have so many of us as believers.

At this time I am very disappointed about the Outlook prompts for password credentials. Perhaps they will fix in the future.

Research

I was able to find the following ADFS White Paper on Office 365 Single Sign-On with AD FS which should provide more details.

I also found info confirming that Outlook wasn’t designed to support Single Sign On.  It has even been quoted “The Office 365 experience for logging on to Microsoft Outlook connections is also not expected to be a single sign-on experience.”KB2535227 (A federated user is prompted unexpectedly to enter their credentials when they access an Office 365 resource)

I apologize for the somewhat rant; but felt I needed to share this before many of you waste a lot of time and investment on trying to get something like this working, to only find out one of the major reasons to use it doesn’t work.

Perhaps Microsoft should read the Internet more before misusing terms such as SSO.

“With SSO, a user logs in once and gains access to different applications, without the need to re-enter log-in credentials at each application.”

http://www.techopedia.com/definition/4106/single-sign-on-sso

Single sign-on (SSO) is a property of access control of multiple related, but independent software systems. With this property a user logs in once and gains access to all systems without being prompted to log in again at each of them.”

http://en.wikipedia.org/wiki/Single_sign_on

Single signon takes away the need for the user to enter further authentications when switching from one application to another.”

http://www.webopedia.com/TERM/S/single_signon.html

Single sign-on (SSO) is mechanism whereby a single action of user authentication and authorization can permit a user to access all computers and systems where he has access permission, without the need to enter multiple passwords. Single sign-on reduces human error, a major component of systems failure and is therefore highly desirable but difficult to implement.

http://www.opengroup.org/security/sso/

– Jermal

O365: Forefront Identity Manager & Office 365 DirSync Failing

I encountered an issue where both Forefront Identity Manager and Office 365 DirSync both failed to start.

My investigation of this after I received an email from @MicrosoftOnline.com which had informed me that Windows Azure Active Directory did not register a synchronization attempt from the Directory Sync tool.

First

I attempted to do was start the Microsoft Online Services Directory Synchronization Service. This had failed because depends on Forefront Identity Manager Synchronization Service which was also no longer starting.

Second

I attempted to start the Forefront Identity Manager Synchronization Service this failed with the following message:

Verify that the service account has permissions to the following registry key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Forefront Identity Manager\2010\Synchronization Service

If the problem persists, run setup and restore the encryption keys from backup.

Third

After my verification I attempted I uninstalled the Office 365 DirSync along with Forefront Identity Manager and SQL which were all installed.  This time around I unable to even install the Office 365 DirSync

All three of my attempts had failed.

So what changed?

I rebooted the system; and after it had resumed the services which worked seemed to no longer function.

Then it *clicked* after much investigation and review.  The question I did not ask.  Could Office 365 exist on the same system that’s also running ADFS.  I soon found out the answer is ” *NO* “.

The Directory Synchronization tool cannot be installed on Active Directory Federation Service.

So I uninstalled the Office 365 DirSync, along with SQL. Followed by the removal of the ADFS Role from the server.

After the restart I installed the Office 365 DirSync again and configured it as I have done before and all is working once again.

And now I and you all know 

I hope this post help you and saves you some time.  I spent a day working on this and waiting for Microsoft to call me.  I seems like I have resolved this issue on my own; once again.

Summery

If your using Office 365 DirSync do NOT enable the ADFS Role if you do, you run the sure chance of breaking your working Office 365 DirSync.

Environment: Windows Server 2012 R2 Update 1 (x64)

– Jermal

Cross Premise Calendar Sharing with Office 365

After a migration to Office 365, user(s) found that they were no longer able to access/edit calendar information, nor were on-premise users able to access/edit calendar details of the Office 365 users.

More info:

In a hybrid deployment of on-premises Microsoft Exchange Server and Microsoft Exchange Online in Microsoft Office 365, you can configure free/busy information sharing so that on-premises users and cloud-based users can see each other’s availability in Microsoft Outlook or Outlook Web App.

However, you can’t grant permissions to create or edit items in another user’s calendar cross-premises. That is, cloud-based users can’t edit the calendars of on-premises users, and on-premises users can’t edit the calendars of cloud-based users. For this level of access, especially when one user must act as a delegate for another user, both mailboxes must exist in your on-premises Exchange organization, or both mailboxes must exist in your Office 365 organization.

To move an on-premises mailbox to the cloud-based organization, or to move a cloud-based mailbox back to the on-premises organization, run the New Remote Move Request Wizard in the Exchange Management Console on the hybrid server. For more information about mailbox migration between the on-premises organization and the cloud-based organization, see the following wiki post in the Office 365 Community: Link

Error messages that users may receive when they try to grant Write-level permissions or perform Write-level actions (such as deleting an appointment in another user’s calendar in Outlook or Outlook Web App) include the following:

  • One or more users cannot be added to the folder access list. Non-local users cannot be given rights on this server
  • You cannot make changes to the contents of this read-only folder
  • You don’t have the appropriate permission to perform this operation

Source: KB2807149

Welcome to Microsoft Office 365 Community

I guess not I can start participating in valuable conversation in the Office 365 Community. Bio Page is now set.  What next?

O365: The target mailbox doesn’t have an SMTP proxy matching

Hello All,

I am still working with some Office 365 issues. This one involves me off-boarding a previously migrated account back to my on-premise Exchange Server.

 

 

I had entered the wrong domain for “Target Deliver Domain” which caused the migration to fail with the following error:

The target  mailbox doesn’t have an SMTP proxy matching…

To resolve this issue

  • Open Exchange Admin Center on-premises Exchange server.
  • Click Mail flow, and then click Email address policies.
  • Select the email address policy, and then click Edit
  • Locate the domain (<domain>.mail.onmicrosoft.com).
  • Use this for Target Delivery Domain and attempt to migrate again.

Ref:  http://support.microsoft.com/kb/2939340