Connect Windows 10 to Azure AD

One of things that really excites me about Windows 10 is its ability to be directly joined to an Azure Active Directory. I think this ability is a major change in the way identity for desktops is going to be managed going forward.

The way that you facilitate a Windows 10 machine doing just that is to firstly go into your Azure AD and select the Configure option as shown above.

You then scroll down to the devices area and ensure that the Users may Azure AD join devices is either set to All or Selected, as shown above.

Then you go to the Windows 10 machine you wish to join to Azure AD and select Settings.

Then select About from the bottom of the menu options on the left.

Then on the right hand side select the link Connect to cloud as shown above.

From the window that appears select Continue.

Enter the credential of a user permitted to connect to your Azure AD and select Sign In.

A few moments later the process is complete and the Windows 10 machine is joined to Azure AD.

If you then check back in your Azure AD and select the user who completed the join and then select the Devices option from the options across the top. That should display a list of Windows 10 machines that are now connected as shown above.

To remove the device from Azure AD simply visit the Settings | About page again and this time select the link Disconnect from the organisation. You’ll be prompted to Disconnect as shown above.

You’ll then need to enter the credential for a local machine administrator (i.e. a users with admin privileges on the Windows 10 desktop).

Enter OK to proceed.

The last step will then be to restart the machine to complete the separation process, much like you would when joining an on premises AD.

So there you have it, joining an Azure AD is very simple on a Windows 10 desktop. Look out for more articles on Windows 10 and Azure AD soon.

Creating a Domain Controller in Azure

Setting up a Domain Controller (DC) in Azure is a little different than on premises. This post is by no means an extensive guide or best practices document on doing that. It is however designed to give you the basics so you can get up and running quickly.

I am going to assume you are starting totally fresh here. The first task is to create a new Azure network in the location that you desire. For more details on doing this see:

Tutorial: Create a Cloud-Only Virtual network in Azure

The next step is to run an Azure virtual machine that will be your Domain Controller. The only step that is slightly different from the norm is that you need to select the virtual network you created previously in the Region/Affinity Group/Virtual network option as shown above.

You then continue on as normal and create the virtual machine and allow it start up.

For more information on creating an Azure virtual machine see:

How to Create a Custom Virtual Machine

Before you connect to the new virtual machine that will be you file server you need to add an additional hard disk to it. From the list of virtual machines you have in Azure select your new machine. Then select the Add button at the bottom of the page. From the menu that appears select Attach empty disk.

Complete the details for the additional disk and save the configuration. For more information on adding an additional disk to a virtual machine see:

How to attach a data disk to a Windows virtual machine

When you log into the virtual machine you’ll see that it already has a dynamic IP address (here 10.0.0.4). This comes from the virtual network you created previously. It is important that you DON’T assign static IP addresses to Azure virtual machines, even in the case of a domain controller. All Azure virtual machines should ONLY have dynamically assigned IP addresses.

If you look at the storage layout of your new virtual machine you’ll see a C: and D:. Beware, D: drive is a temporary drive that gets erased and recreated on reboot. Thus, the only stuff you want on there is temporary stuff like the page file. Good practice is not to have the Active Directory databases on the boot partition, because if that becomes inaccessible then bye bye AD, unless you have a backup. This is the reason why we attached an additional disk to our new virtual machine.

Everything now is pretty as it would be with on premises equipment. Go into the Windows Disk Management console and initialise the new disk.

Create a new volume on this additional disk and format it. At the end you should have a drive letter you can access. Here, F:.

If you again view the storage configuration of your virtual machine you should see a new disk (here F:) which will be the destination for the AD database.

Things remain the same when you configure your server to be a domain controller. Simply go in and add the role as you would normally.

Allow the configuration to complete.

Once the role has been enabled you now need to raise the server to being a domain controller exactly how you would on premises. The only difference is that you should re-locate the AD DS database, log files and SYSVOL to the disk you added (here F:).

Just before you complete the process of raising the server to be a domain controller, you’ll see the above warning about a domain controller requiring a static IP address. Again, in Azure this DOES NOT apply. In Azure we want all servers to have dynamic IP addresses.

Once you Domain Controller is running go into the DNS manager, right mouse click on the DNS server (here the domain controller) and select properties. In the Forwarders tab remove any IP address listed.

The last step is to go back and edit the properties of your virtual network. In the Configure tab for the network you will find the option for dns servers as shown above. Add the IP address and machine name here and save it. Although, the IP address assigned is dynamic it is on a extended lease so it should effectively ‘remain’ static. if you do power up and down your DC regularly for testing like I do, simply ensure that your DC is the first machine your fire up on that virtual network.

So now you have an Azure hosted Windows Domain Controller (DC) without too much additional fuss.

So now, if I want to add another Azure virtual machine into this network and onto the domain, I simply run up an Azure virtual machine as normal. When you do you’ll see it get a different IP address (here 10.0.0.5, while the DC is 10.0.0.4).

Then, as you would anywhere else, simply add that machine to the domain. You’ll be prompted for administrator credentials to verify the domain join.

If that is all you now have a second machine on this domain.

So in summary, the key points with a Windows Domain Controller in Azure is:

– Add an extra disk and install the AD database, logs and SYSVOL here

– Don’t give DC a static IP address

– Assign the DC IP address to the DNS setting in the virtual network configuration.

For more details on doing this see:

Install a new Active Directory forest on an Azure virtual network

Need to Know podcast–Episode 86

I’m joined by Jeff Alexander from Microsoft to talk Windows 10. As excitement builds ahead of the July 29 release we cover off things such as what the upgrade entails, what are the benefits of Windows 10 and why most people should consider an upgrade as soon as they can. There was just so much to talk about that we agreed to do a follow up session in the near future. So download, tune in and begin your upgrade to Windows 10 today!

You can listen to this episode at:

http://ciaops.podbean.com/e/episode-86-jeff-alexander/

or subscribe to this and all episodes in iTunes at:

https://itunes.apple.com/au/podcast/ciaops-need-to-know-podcasts/id406891445?mt=2

The podcast is also available on Stitcher at:

http://www.stitcher.com/podcast/ciaops/need-to-know-podcast?refid=stpr

Don’t forget to give the show a rating as well as send me any feedback or suggestions you may have for the show. I’m also on the hunt for some co-presenters so if you are interested on being a regular part of the show please contact me.

Resources

Jeff on Twitter – https://twitter.com/jeffa36

Jeff’s About.me page – https://about.me/jeffa36

Windows Insider program – http://insider.windows.com

Windows 10 uservoice – https://windows.uservoice.com/forums/265757-windows-feature-suggestions

Windows 10 Blog – http://blogs.windows.com

Configuring Yammer Dirsync

I’ve recently blogged about using DIRSYNC to connect your local Active Directory (AD) to Office 365. It is one of the most popular posts on this blog and you can find it here:

Windows Azure Active Directory Sync tool (DIRSYSNC) – the basics

I have followed this up even more recently with a post about the updated DIRSYNC tool called Azure Active Directory Sync Services and you can find that here:

Azure AD Sync Services tool – the basics

Finally, I have posted about the preview of the tool that is replace Azure AD Sync Services called Azure AD Connect and that you can find here:

Azure AD Connect (Preview) – Install

You may think these are the only tools used or required to copy you local AD to Office 365 services. They aren’t. Hopefully, you know that Yammer is now included free with many Office 365 plans and Yammer also contains user information. In fact it is possible to copy some of this user information from your local AD.

The place to start is the:

Yammer Directory Sync 3.0 Admin Guide

but before you get too far into the weeds what benefits does Yammer DIRSYNC provide?

As the guide says, after you set up this integration product, users will be able to be automatically:

– removed from your Yammer network when you disable them in AD

– invited to your Yammer network when you add them to AD

– updated with new profile information when you update their attributes in AD

and that is basically it. My personal take on this is that Yammer DIRSYNC doesn’t really provide a lot of benefit for smaller organisations that don’t have thousands of AD users and who don’t have large amounts of turnover within their staff. If that is your business or your customer’s business then you can stop reading here and not have to worry about this any more.

However, I hope that you are at least somewhat curious as to how the whole configuration process of Yammer DIRSYNC is completed, and you might also be interested in some of the ‘challenges’ I faced getting this to work. That, at least, I hope makes you read through the volume of information I’ll detail here with the process I went through.

This attempt to configure Yammer DIRSYNC was completed in a test environment. I created a new clean Office 365 E3 tenant. I installed a new clean Windows Server 2012 R2 server in Azure. I created a new set of local AD users and used AD Connect (Preview) to get them copied to the Office 365 tenant. I then assigned them licences. All of this was prior to getting Yammer DIRSYNC operational.

So the plan was now to install Yammer DIRSYNC on the same server as Azure AD Connect (Preview), which as it turns out is the Domain Controller (DC). Of course best practice should always be to install any Office 365 user syncing tool (Office 365 DIRSYNC, Azure AD Services, Azure AD Connect, etc) onto a separate members server. The same would also go for Yammer DIRSYNC, however not all businesses have this luxury when it comes to rolling out addition on premises hardware do they? Also to my mind it doesn’t make sense to roll out more on premises hardware when the real desired aim to eventually move everything to the cloud. Thus, in this case, everything will reside on the Domain Controller.

When a user is invited to join a Yammer network they receive an email like shown above that provides them a link to get started with Yammer. When you enable Yammer in Office 365 using this process that I also recently detailed:

Enabling Enterprise Yammer in Office 365

Users won’t automatically receive such email invitations, they just need to select the Yammer icon from their app launcher inside the Office 365 portal. Thus, if you are looking to drive Yammer adoption throughout your organisation, having an email automatically sent to new users telling them about Yammer can provide a benefit. This you can do when Yammer DIRSYNC is enabled.

The first step in enabling Yammer DIRSYNC is to create a service account to be used by the DIRSYNC process. Thus, I went into my local AD, created a new user called Yammer Service and allowed that to sync to Office 365 (as I have Office 365 DIRSYNC enabled).

An interesting question gets raised here. What securities does this Yammer service account require both on premises and in Office 365? From what I can determine, locally, the Yammer service account can be just a normal user in the local AD and in Office 365 it has to have at least a mailbox license. This means if you only have Office 365 Suite licenses (i.e. SharePoint, Exchange, Skype for Business, together) you will need to either dedicate a complete license for this service account or purchase a stand alone Exchange Online license and add this to your tenant (which you can do now as Office 365 plans allow you to mix and match plans in one tenant).

Once the Yammer service account has been created in local AD, synced to Office 365 and assigned a license you simply login as that account and then navigate to Yammer so the service account is now an activated Yammer user. All this is the normal way you create and activate any Yammer user.

The next step is to login as an existing Yammer verified admin (typically an Office 365 Global Administrator) and select the Yammer enterprise admin area. Once there you will find an Admins option as shown above. Here you promote the new Yammer service account to be a verified Yammer admin.

Doing so means that the Yammer service account will have full control over Yammer (i.e. a Yammer admin) without the need to be an Office 365 Global Administrator (which gives them full control over more that just Yammer in Office 365).

Once you have added the Yammer service account as a Yammer admin you will also need to select the Grant Verified Admin button above to give that account full rights in Yammer.

You should now see the Yammer service account (here called Yammer Service) appear as a Current Admin as shown above.

What I then tried to do was go back into the Office 365 licensing and remove the license for the Yammer service account as I wanted to conserve licenses given I was using an Office 365 suite. Problem is when you do that (i.e. assign no license) you also don’t appear to get a Yammer license. You also don’t get a mailbox license which it turns out you’ll need later.

So, any Yammer service account requires at least a mailbox license in Office 365 from what I can determine.

The next step in the process is to download the Yammer.Dirsync.Setup program to your local on premises server on which the sync is gong to take place. You can download this software from:

http://go.microsoft.com/fwlink/p/?LinkId=511986

You kick off the installation and change the install directory if desired. if not then it will install into:

c:\program files (x86)\yammer\directory sync\

Select the Install button to continue.

You’ll then see the software being installed.

When that process is complete you’ll see the above screen. You need to insert the Yammer service account and password in the top part of the options to the right.

Now as you can see, when I did this I received the error Unexpected login failure even though I knew the password was correct. The solution lies here:

https://support.microsoft.com/en-us/kb/3015691

Which in essence this is telling you that you need to generate a unique ‘app’ password for this account to move forward.

To do that you’ll need to log back into Yammer as the service account and select the three dots in the top right and then Apps from the menu that appears.

In the All Apps area towards the bottom of the page select the Yammer tab.

Locate an app and select it by name. Here I located the Windows Phone app and select the hyperlink Windows Phone.

This will show you something like the above. The information you require is in the lower left of this window.

here you should see your Yammer service account email and a temporary password. You will need to use this back with the Yammer DIRSYNC program.

Note that the app password is only available for a short period of time, so copy it from here and then immediately head back to the Yammer DIRSYNC configuration.

Place this Yammer app password in the password field and select the Login button to continue.

I next received the above message which I have no idea what it meant so I simply selected OK to continue.

The next step is to put in the details for your local domain. Here I specified my domain controller and select the Login button.

Doing so then placed my domain controller in the window. Strangely, there is no continue button so I simply selected Validate from the options on the left to proceed.

Now select the Start Validation button.

The validation process will then commence.

At this point I received the error:

Invalid or missing attributes for required attribute(s): mail

After much trial and error I discovered that the apparent reason for this validation error is because the email attribute for the user is not set in the local AD. You can see the location of the attribute in the above screen shot of a users properties in AD.

In an environment with no local Exchange server you have to wonder how this field is going to get populated? Clearly, in my case it has to be done manually. That could be quite a pain if you have a lot of users!

Now, with all the users in the local AD having their email field populated I could successfully complete the validation step as shown above.

Again, no real next button here so select Sync from the options on the left to continue.

To continue you need to enter mail server and user details as shown above. This is the reason why you need to ensure that the Yammer service account has at least an Exchange Online license.

The server in this case will be Office 365 which for SMTP is:

smtp.office365.com

Port is:

587

and Enable SSL should be checked.

A number of articles I found said that you need to ensure the FromAddress field in the EmailNotificationSettings section in the file globalsettings.config.json should be manually changed from the default of noreply@yammer.com to being the same as in the Username field above, which should be the email address of the Yammer service account.

When I searched the directory that Yammer DIRSYNC was installed but I couldn’t find the globalsettings.config.json file. Turns out it is actually located in:

C:\ProgramData\Yammer\DirSync

by default. You may, as I had to, change the default view in Windows Explorer to actually see and navigate to the directory.

Turns out there is now a Yammer DIRSYNC icon in the system tray that if you right mouse click on show a menu as seen above.

If you select About from the menu that is displayed you will see the above dialog appear.

If you then select the Advanced Configuration button a Windows Explorer window will be opened at the location of the globalsettings.config.json file which again is located at:

C:\ProgramData\Yammer\DirSync

You can open the json configuration file with notepad and make the appropriate change from noreply@yammer.com to the email address of the Yammer service account you are using. Close and then save the json configuration file.

You then return to the Yammer DIRSYNC installation program and complete all the details.

You should also then be able to select the Send Test Email button to verify everything is working.

After which you should receive a green check mark as shown above.

To proceed, select the Apply button to the right which should now be available.

The Enable Sync button at the button of the window should now be available and The Status should read Not Running as shown above.

Select the Enable Sync button to proceed.

You should see the Status field runs through a few options such as Validating Settings as shown above.

If there are no issues the Status should say Running as shown above.

You can close the Yammer DIRSYNC program and it will continue to run in the background. You should find a Yammer DIRSYNC icon in the system tray which you can right mouse click on and select Open from the menu that appears to view the program again if needed.

Here is the Microsoft documentation on installing the Yammer DIRSYNC application:

Install Yammer Directory Sync

Now according to this:

The Yammer Directory Sync utility now queries Active Directory every 60 minutes and adds, updates, and suspends users, as appropriate.

The log files:

service.log – contains sync errors
ui.log – contains UI errors

are located in the directory:

C:\ProgramData\Yammer\DirSync

along with the json configuration file.

What should happen after a a period of time is that if you look in Yammer as an admin under the Directory Integration menu option you should see that it has been enabled as you can see above.

If you return to the on premises server you installed Yammer DIRSYNC on you will find a service called Yammer Directory Sync 3.0 as shown above.

Now, what I found was that Yammer DIRSYNC service was taking a very long time to actually sync. This was probably due to the fact that the first sync is quite large but my overall experience is that Yammer sync is quite slow and there is now way to force it like you can with Office 365 DIRSYNC. You simply have to wait.

When I look at the service.log file after this et I was seeing an error:

INFO [2015-06-11 23:18:28,807] – Scheduled interval set to 60 minutes
INFO [2015-06-11 23:18:28,807] – Starting with sync enabled: False
INFO [2015-06-11 23:18:44,224] – IPC Server running successfully
INFO [2015-06-11 23:19:51,595] – Registering callback for Yammer.DirSync.Core.IPC.Transport.NamedPipeServerBus+CallbackReference
INFO [2015-06-11 23:20:06,842] – Changing sync enabled to True
ERROR [2015-06-11 23:20:06,880] – Error saving enabled state
System.UnauthorizedAccessException: Access to the path ‘C:\ProgramData\Yammer\DirSync\globalsettings.config.json’ is denied.
   at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
   at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy, Boolean useLongPath, Boolean checkHost)
   at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share)
   at Yammer.DirSync.Core.FileSystemRepositoryBase`1.Save(T settings)
   at Yammer.DirSync.Core.FileSystemRepositoryBase`1.Save(Action`1 update)
   at Yammer.DirSync.Service.ScheduledSyncService.SetEnabled(Boolean status, Boolean interrupt)
INFO [2015-06-11 23:20:07,014] – Starting sync because sync state changed.

After another long period of troubleshooting what I found the solution that removed this access issue from the log file was changing the Yammer Directory Sync service to run as a domain administrator rather than the Network Service.

The other issue I saw a lot of in the log was:

Waiting for previously running sync to complete.

So in the end I left the sync process running and went away to do other things.

Eventually after at least 4 hours I returned to find that syncing was now successful.

INFO [2015-06-12 00:09:39,647] – Sending remote job Suspend with 1 users
INFO [2015-06-12 00:09:40,674] – Data received for job syncie-2-e2007c89-007f-44c6-8bd8-8e66b4ab6e9e, processing has begun.
INFO [2015-06-12 00:09:41,589] – Waiting for previously running sync to complete.
INFO [2015-06-12 00:49:51,074] – Yammer Directory Synchronization has completed.
1 Users Added
1 Users Updated
0 Users Suspended
0 Pending Users Deleted

I find it interesting that it took at least 4 hours to initially sink a clean demo system with only a handful of users! Again, my experience has been that Yammer DIRSYNC is quite a slow process.

INFO [2015-06-12 00:49:51,157] – Sync attempt finished with status: Success
WARN [2015-06-12 01:50:03,650] – Some attributes do not exist in directory CIAOPS-DC2: title, physicalDeliveryOfficeName, telephoneNumber, mobile, department, proxyAddresses
INFO [2015-06-12 01:50:03,774] – Reading directory users
INFO [2015-06-12 01:50:09,522] – Completed reading directory users. 0 total users.
INFO [2015-06-12 01:50:09,897] – No changes for sync phase CreateOrUpdate
INFO [2015-06-12 01:50:10,278] – No changes for sync phase Suspend
INFO [2015-06-12 01:50:10,278] – Yammer Directory Synchronization has completed.
0 Users Added
0 Users Updated
0 Users Suspended
0 Pending Users Deleted

As you see from the subsequent sync log above I was still get warnings which I wasn’t really sure what they meant or how to fix them, so I ignored them.

However, now after I created a new user in the local AD, allowed it sync to Office 365 via Office 365 DIRSYNC, then assign an Office 365 license, waited some more for it to sync to Yammer, the new user did receive for Yammer via email as you can see above.

Phew, that is a lot of work just to get that one email!

I then also deleted a user from the local AD, saw it removed from Office 365 and also no longer be able to login to Yammer so I am confident that the deletions in Yammer DIRSYNC also work as expected.

At this point I started to get more errors occurring with the Yammer DIRSYNC program to the point where the Yammer sync process would stop. I did some initial research on what might be causing these issues but abandoned that after a short while as I couldn’t really see much ROI in Yammer DIRSYNC.

At this point I abandoned further work on Yammer DIRSYNC as I had gotten it working.

Summary

The smaller the organisation the less of a need for considering Yammer DIRSYNC. I don’t believe it provides much real value unless you are adding or removing lots of users from you AD on a regular basis.

I found a lot of issues getting Yammer DIRSYNC operational and keeping it running in a small test environment. Maybe I overlooked some things or did stuff wrong, but I really couldn’t find a lot out there to help. I have included some helpful sites below in the references section.

It seems to me that the Yammer single sign on experience will be driven in future from Office 365 and Azure rather than a local application on a server syncing local AD. Hopefully something Azure AD Connect will one day incorporate all the synchronization Yammer requires. I expect this to be the case as Yammer becomes more and more integrated with Office 365.

The synchronisation of information to Yammer is very slow and only happens once an hour at most. I found now way to be able to force this synchronisation.

If you do have issue with Yammer DIRSYNC don’t be afraid to raise an Office 365 support ticket. The Yammer support people were very obliging and knowledgeable.

References

http://www.lifeonplanetgroove.com/setting-yammer-directory-sync-office365/

https://about.yammer.com/success/wp-content/uploads/sites/13/2013/05/Directory-Sync-3.0-Install-Guide.pdf

https://about.yammer.com/success/wp-content/uploads/sites/13/Directory-Sync-3.0-AdvancedConfig-Guide.pdf

https://jorgequestforknowledge.wordpress.com/2014/10/08/setting-up-yammer-dirsync/

http://channel9.msdn.com/Events/SharePoint-Conference/2014/SPC368

How to audit users in Yammer – https://technet.microsoft.com/en-us/library/dn783348.aspx

http://blogs.technet.com/b/askyammer/archive/2015/05/18/yammer-directory-sync.aspx

Plan for Yammer DIRSYNC – https://technet.microsoft.com/en-us/library/dn799027.aspx

Azure AD Connect (Preview)–Install

In a recent post I detailed the current replacement product to DIRSYNC:

Azure AD Sync Services tool – the basic

In there I noted that this will soon be replaced with Azure AD Connect which is currently in preview:

Azure AD Connect Preview 2 is available

I thought I’d run through a short walk through experience of installing Azure AD Connect just so you can see. When the product comes out of preview I’ll do something in more detail.

You download and run the tool.

This will give you an icon on your desktop and launch the install wizard.

You need to agree to the license terms.

You select the Continue button.

You’ll be prompted to install any prerequisites. Press the Install button to continue.

You can select any custom configuration you desire. Press the Install button to continue.

You should now see the service commence installing by installing SQL Express as AD Sync Services did.

It will then start installing the Synchronization Service.

Next, you’ll need to enter you Office 365 credentials and select Next.

You should then see the connection to your tenant being made.

At this point you can elect to use the express settings or work through the customised options. The express options will automatically:

– Configure synchronization of identities in the current AD forest

– Configure password synchronization from on premise AD to Azure AD

– Start an initial synchronization

– Synchronize all attributes

For most standard configurations this is fine but we will select the Customize option rather than the Use express settings here to see all the options.

Select the Password Synchronization option and Next to continue.

Next, enter you on premised domain credentials and select Add Directory. If you have more local domains you can add these but normally all you need to do after adding the local domain is select Next.

The local AD information will be retrieved.

Here is where you can now elect to filter what is synchronised. Since we only have one domain we’ll elect to synchronise everything and press Next to continue.

Normally you select User are represented once across all directories here and press Next.

This option allows you to match on premise users with those in the cloud via different attributes. best practice is normally to leave the default options and select Next to continue.

There are lots of options here that are in preview. Select the Password writeback to sync information from you local AD to Office 365. Remember, that at the moment two way sync will not occur unless you have an Azure AD Premium subscription, which is not part of Office 365. Office 365 only includes free Azure AD.

The hope however is that when Azure AD Connect comes out of preview the ability to sync passwords from local AD to Office 365 and back will be included with all Office 365 plans. However, right here, right now for two way syncing you need an Azure AD Premium subscription.

Select Next to continue.

Everything is now ready to configure so press the Install button to proceed.

The wizard will now do its thing.

Configuring you Office 365.

Updating rules

The on premises domain.

Then enables password sync.

In a few moments the process will be complete and you can press Exit to end.

As before, you’ll find a number of new applications installed.

The Synchronization Service will give you the ability to monitor the progress real time.

if a user tries to change a password in their web portal they will be greeted with the above message basically informing them that it has to be on premises NOT in the cloud.

An Office 365 administrator can reset the password via the admin portal for a user but after the next sync has run from the local AD that changed password will be overwritten with the one from on premises.

Thus, there is not a huge change between what we have now with Azure AD Sync Services and what is coming with Azure AD Connect. At this stage, you still need and Azure AD Premium subscription to do password write back to on premises as well as many of the advanced features. The hope is that this will change when Azure AD Connect come out of preview. Fingers crossed.

Windows 7 and 8 machines come to Azure

Oh man, this blog is currently turning into the ‘I love Azure’ site isn’t it? But WOW, here’s another announcement that is a game changer in my mind.

Microsoft Azure now has Windows 7 and 8 virtual machines as you can see from the above screen shot. Before this I was using Windows Server 2012 as a workstation to have a ‘clean’ machine to test and demo Office 365.

With the availability of these new desktop Windows systems I can create an even more EXACT test/demo installation in the cloud. This is BRILLIANT since I can now dozens of machines in Azure to test all sorts of scenarios. I would have run out of disk space long ago if even attempted this on my workstation.

Here’s another thing to ponder. if Windows desktop systems are now available via Azure how far away can a full blown Virtual Desktop Offering be? How long can it be before this Virtual Desktop becomes an option in Office 365? My guess? Not long.

Enough. I’m off to spin up more Azure demo machines. What can I say? I love Azure more and more every day!

Clarification – I overlooked the fact that these images are currently only available to MSDN subscribers. Also these images are not meant for production just testing. However, none the less, it certain tells me where all this is going.