In my last blog post here, I wrote an introduction to Azure Resource Manager (ARM). ARM is the toolset Microsoft has added to Azure for provisioning and controlling resources in Azure.

ARM has the tools to help you develop scriptable virtual machines deployments within your own tenant, but the process is not necessarily as simple as you might think. In this blog post, I’m going to walk through my process of learning to create a simple machine template, and deploying it to my own Azure tenant. Hopefully over time, I will grow this process into a larger project that works for more complex deployments.

Various tools diagnose and troubleshoot problems with Autodiscover, a web service in Microsoft Exchange Online that enables mailbox admins to configure user profile settings.

Azure Resource Manager (ARM) is Microsoft's platform for deploying and managing resources within Azure. ARM allows you to build resource deployment templates using PowerShell and JSON scripts to build repeatable and consistent deployments in Azure.

I figure it's time for me to learn how this whole Azure thing works, and the best way for me to get it all straight in my mind is to be able to explain it to you. Some of what I cover in this blog post may be a little basic, so if you’re already using ARM effectively you might want to skip to the next blog post.

When you create a new mailbox in Exchange Online, that mailbox comes with specific settings, features, and protocols enabled. As an Office 365 administrator, you have the ability to go back and modify these settings later if—for instance—you don't want users to have their default mailbox size limit set at 100 GB, or if you want a specific retention policy applied to that mailbox.

If you'd like to take the next step with such customizations and have them automatically applied to mailboxes, then this is the blog post for you. The Office 365 roadmap shows that Microsoft is in the process of making enhancements to mailbox plans.

Back in September of last year, I wrote an article about Multi-Factor Authentication for Office 365. Since the cloud refuses to stand still, it looks like it’s time to update that post with some new information.

The original problem of Office 365 not being a single application, but instead a collection of applications, still exists. The Multi-Factor Authentication (MFA) story for the individual parts of Office 365 is, unfortunately, still disjointed and inconsistent. It will most likely be years before Microsoft can build all of the services within Office 365 into a consistent and operational framework, if such a change could even happen.