Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

My company is quite young and small, but since we're growing, we want to rollout some software deployment solution. We haven’t decided which one yet, but they usually need a Windows Domain, and we don't have one. We use Office 365 for everything like Outlook, SharePoint or Lync.

In another question, I asked how to migrate the users from O365 to a Windows AD, and it seems the only way is to csv-export from o365 and csv-import into Windows AD. Then we activate DirSync which syncs the accounts by overwriting all attributes in O365 by the ones provided in the Windows AD. Activating DirSync also moves the source of authority.

Many of the attributes in O365 have no analogy in the Windows AD and also, the other way around.

If we cannot migrate some attributes or have some errors in the process, some cloud applications like Lync, Outlook and SharePoint may stop working properly.

We could test everything that comes to mind but there might be issues we do not cover.

Is there a comprehensive documentation on which cloud application uses which attributes? I’m interested in SharePoint, Exchange/Outlook, Lync and the offline applications.

How would I test the effects of a missing/erroneous attribute? Creating a user for each testcase, logging in as them and testing every feature of every app?

The process sounds quite error-prone. Is there some better approach to this? Has anyone done this before?

share|improve this question

2 Answers 2

Scary the situation you're in, but not impossible, and can be solved easily by enabling "SMTP matching", which is a process of transferring the source of authority from your Office 365 to your local active directory. this can be achieved by matching the SMTP address of your Office 365 accounts to the SMTP address of your Active Directory accounts, and using the DirSync tool to sync the account information from your local AD to the Office 365 network.

In order for the SMTP matching to work, you will need to recreate the user accounts and groups from your Office 365 to your local Active Directory domain, exporting user info from your Office 365 to a CSV file might give you a good start to import the CSV info back to AD, but the problem is that the default export from Office 365 doesn't generate all the information and attributes you need to import back to active directory, and some of the attributes created from Office 365 doesn't match the attribute names in AD, so you may need to do some renaming for the attribute names in the CSV file before importing back to AD.

Mind you that you don't need ALL the attributes from Office 365 for this to work, you only need to create an account in AD that matches the same SMTP address in Office 365 to change the source of authority, all the other attributes like phone number, address, manager and so on are cosmetics at this point and can be imported later, also note that once the source of authority/information for the user accounts changes to be AD, the cosmetic user information in AD will overwrite whats on Office 365, so try your best to import/export all the available information before enabling DirSync synchronization.

If you think about it, what you really need to do will boil down to this

  1. Export the account information from Office 365 by using the PowerShell command Get-MsolUser | Select <attributes> | Export-CSV -Path <FileLocation>

The usable attributes that you can use for this command are: City, Country, Department, DisplayName, Fax, FirstName, LastName, MobilePhone, Office, PasswordNeverExpires, PhoneNumber, PortalSettings, PostalCode, SignInName, Title, UserPrincipalName

  1. Import the account information to AD using the Powershell command Import-CSV <FileLocation> | New-ADUser

You will need to rename/add attributes to the CSV file in order for the import process to be successful, a list of all the attributes that you can import and use can be found here: http://technet.microsoft.com/en-us/library/ee617253.aspx

  1. Recreate your groups from Office 365 into AD, and make user placement as in the Office 365 network.

  2. Enable SMTP matching using the following KB article: http://support.microsoft.com/kb/2641663/en-us, more information here: http://stellark.itgroove.net/2014/05/21/dirsyncsmtpmatching/

  3. (Optional) Use the Microsoft IDFix tool to insure that the information created in AD are compaitble with the Office 365 network, the tool can be found here: http://www.microsoft.com/en-us/download/details.aspx?id=36832

  4. Enable DirSync, a good article to follow can be found here: http://social.technet.microsoft.com/wiki/contents/articles/19098.dirsync-how-to-install-the-directory-sync-tool.aspx

  5. (Optional) you may test migrating a couple of users first before moving your entire company, this can be done by placing your test users in an OU inside AD, and then ask DirSync to only migrate the content of the OU to Office 365, more info can be found here: http://blogs.technet.com/b/praveenkumar/archive/2014/04/11/how-to-do-ou-based-filtering-in-office-365.aspx

In theory, this will change the source of authority to your AD, and the user accounts/groups/passwords will be imported from AD to Office 365, I can't think of a anything that is going to break for your users or Office 365 if you do this with careful planning and testing.

Hope this helps, and let me know if you need to do further discussing on this, would be happy to help.

share|improve this answer
    
This is precisely what I've already done. I wrote it in my answer to my other question which I linked in the question above: serverfault.com/questions/647241/… Nevertheless, your collection of links will be of help to others I hope. Also, your fifth point is new to me, so thanks for that. –  sinned Dec 9 at 8:25

Take a look at opsi (opsi.org) for a deployment solution that does not require AD. It is free (opensource, gpl) and works great, but you definitly want some help in setting it up, depending on your inhouse know how with linux and windows. There are some advanced features that cost money,too.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.