How do we keep domain and office 365 hosted exchange  passwords in sync with sbs 2011 standard?

BeGentleWithMe-INeedHelp
BeGentleWithMe-INeedHelp used Ask the Experts™
on
Sorry if this seems so ignorant.

A couple different companies are moving to office 365 for hosted exchange from their sbs 2011 standard network (We'll keep the server around for file sharing for now).  Each location has about 15 users.

I know from dealing with SBS essentials that it keeps the domain passwords in sync with the office 365 hosted exchange passwords.

There's a DIrSync tool I walked through in office 365 admin and it dissuades you from doing that for less than 50 users.

a) do you agree that there's no need / not wanted to keep the office 365 password in sync with the inhouse domain computer login password?
b) If you don't agree, with SBS 2011 standard, what are the options to be able to keep them in sync?  I thin k I saw something about azure active directory.  is that the only way?
c) If Azure AD is needed, what's the cost?  That's a different interface, exprience than office 365?  Is pricing like office 365 (a flat amount per month) or does it depend on usage - number of accesses, etc?

there;s likely loads of more questions I have once I get pointed in the right direction.,
Comment
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Saif ShaikhServer engineer

Commented:
yes Azure AD is good option for syncing password from onpremise. You cannot install Azure AD connect on an SBS server since it uses it own SQL database.

You need to have a separate member server joined in domain.

We need the Azure AD server with Windows 2008 R2 SP1 and above operating system for installation of AD Connect. The following versions of the Windows Server operating system are supported for DirSync:
•      Windows Server 2008 R2 Standard, Enterprise or Datacenter edition with SP1 or later
•      Windows Server 2012 Standard or Datacenter
•      Windows Server 2012 R2 Standard or Datacenter
Saif ShaikhServer engineer

Commented:
Before implementing Azure AD connect aka dirsync you need to Set UPN on all users to match the Primary SMTP address in AD. for all syncing users i.e. from .local to .com

So basically you can go to domains and trust and add the UPN for the domain which is registered in O365 tenant.
Saif ShaikhServer engineer

Commented:
c) If Azure AD is needed, what's the cost?  That's a different interface, exprience than office 365?  Is pricing like office 365 (a flat amount per month) or does it depend on usage - number of accesses, etc?

Azure AD connect is implemented in your onpremise environment so there is cost with regards to hardware and no cost with regards to O365 license and all.
Ensure you’re charging the right price for your IT

Do you wonder if your IT business is truly profitable or if you should raise your prices? Learn how to calculate your overhead burden using our free interactive tool and use it to determine the right price for your IT services. Start calculating Now!

OK, maybe I'm not asking the right question? Or you misunderstood?

Or more likely - this just reaffirms my thinking that Microsoft is soooo convoluted and F__d up.

Their Azure AD, based on Azure, their CLOUD BASED SERVERS.... needs MORE hardware at my office and is implemented in house?
Saif ShaikhServer engineer

Commented:
Yes, If you need to sync passwords then yes no choice.

If you do not want to sync passwords, then users domain password and email password will be different.

You also have an option to install Azure AD connect on a DC if it has the above requirement of OS passed just to SAVE HARDWARE COST..........................MICROSOFT.........................
what do most people do?  why do they call it azure AD then?  

So am I way off base? i thought Microsoft is pushing everything to the cloud... you have your onedrive for shared files, hosted exchange.  And AD in the cloud. So people at work have just desktops, no servers in the office?
Server engineer
Commented:
Azure AD is Microsoft Azure Active directory.

So when you create a new user in O365 portal it shows as "In cloud" (User object in Azure AD).

When you setup a new object in local onpremise AD and synchronize the same user using dirsync then the user in O365 shows as "synced with AD".

So to manage an in cloud user you use O365 portal like changing password, adding smtp alias. But managing a locally synced with AD user has to be managed from local AD.

So here basically for this user "synced with AD" and attribute level change has to be done from the local AD and not O365.

If you are decommissioning your exchange server after all users are "synced with ad" AND have O365 license, then you shut off dirsync from O365 portal or O365 power-shell,

All users will eventually change to "Incloud" , hence the purpose of dirsync implementation is that you do not want to add 100 of users manually to O365 Azure AD.

Those have to be synced first and then you decommission your local AD so that there is synced object or I say cloned object in Azure AD

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial