O365

Office 365: Convert Mailbox to Shared Mailbox after Cutover Migration

When performing a cut-over migration the Exchange attribute indicating that the mailbox was a shared mailbox is lost. To correct this I have done the following steps:

List out all of the shared mailboxes form my on-premises Exchange and export them into a CSV file.

Now prepare the CSV file with the list of user principal names of all mailboxes to be converted. Make sure the column header for the user principal names is “UserPrincipalName”

Now we run the following powershell script to change the mailbox type of all items in the CSV file.

Please note

Running Exchange Online Powershell commands / scripts requires you have had installed the Microsoft Online Service Sign-In Assistant, Windows Powershell, Windows Azure Active Directory Powershell

For more info:

http://www.microsoft.com/en-us/download/details.aspx?id=41950

http://jermsmit.com/azure-active-directory-module-for-windows-powershell-how-to-connect/

 

Tech Short: Office365 – Convert select on-premises mailboxes to mail-enabled users

When you convert on-premises mailboxes to mail-enabled users (MEUs), the proxy addresses and other information from the Office 365 mailboxes are copied to the MEUs, which reside in Active Directory in your on-premises organization. These MEU properties enable the Directory Synchronization tool, to match each MEU with its corresponding cloud mailbox.

Using the steps provided here I was able to export a list of only user mailboxes and leaving out other mailbox types

Run the following PowerShell command:

The following full steps of what to do next can be found here: http://community.office365.com/en-us/w/exchange/835.cutover-exchange-migration-and-single-sign-on.aspx

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

 

Tech Short: Convert a Mailbox, Exchange 2013

Here are some steps that worked for me in converting a user mailbox to a shared mailbox.

Info: You can convert the following mailboxes from one type to another

  • User mailbox to resource mailbox
  • Shared mailbox to user mailbox
  • Shared mailbox to resource mailbox
  • Resource mailbox to user mailbox
  • Resource mailbox to shared mailbox

Example reason why you might wan’t to do this:

You have a mailbox account with the name of  bookclub and are looking make it a shared account because its consuming a license. To address this we will convert it to a shared mailbox account by issues the following commands in the Exchange Management Shell

 

If you have multiple accounts, the following steps may apply to you

 

Please note the following csv document formatting:

Ref: http://technet.microsoft.com/en-us/library/jj710164%28v=exchg.150%29.aspx

 

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

 

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?