Tag Archives: office 365

Moving a small on-prem environment to Azure/ O365 – Part 1

This posting is ~3 years years old. You should keep this in mind. IT is a short living business. This information might be outdated.

It was a bit quiet here due to the current COVID 19 pandemic. But now I’m back with a pretty interesting story on how my colleagues and I moved most of our on-prem server stuff to Microsoft Azure and Office 365.

Microsoft 2020 (c)

It all started with the COVID19 lockdown in Germany in March 2020. We moved into our home offices after setting up a small VMware Horizon View deployment to access our PCs using physical View Agents and manual desktop pools. Most projects were stopped, and we did most of our work remote. No lay-offs or short-time work.

We were running a small VMware vSphere cluster for a couple of years. Nothing fancy: Two HPE ProLiants, vCenter, two DCs, File-/ Printserver, WSUS, Exchange, Linux maschines for web services, Sophos UTM, a pfSense, View Connection Server, UAG, ADFS/ ADFS Proxy, PKI etc. In sum 18 VMs on two hosts, some VLANs with firewalls in between etc. We were running Exchange 2016, AzureAD Sync, Exchange Hybrid, but we only used Microsoft Teams from our Office 365 deployment. Veeam Backup & Replication was used for backups, a backup copy to a NAS and some Robocopy jobs that moved Veeam Backups to USB drives for DR. Everything was pretty simple and designed to work without much operations. Our focus is on our customers, not on our internal IT. It was stable, secure and pretty slick.

In March 2020 we asked “What if?”. What if we lose our offices due to a fire (we are located in a bigger office building and we had a couple of fire alarms this year due to remodeling work). How can we work if your DSL line is cut? How can we get our backups offsite? How can we modernize our IT withtout big invests? Money, that we don’t spend on our internal IT can given to our employees. ;) (By the way, that’s the same reason why we try to drive smaller and more efficient cars…).

We developed a couple of ideas, including new servers, storage etc. and put that stuff into a datacenter. But in the end, we decided to move most of our stuff to Microsoft Azure and Office 365.

I want to share some of the things we have learned on the road to Azure.

Initial assessment

We used the Azure Migrate Server Assessment tool to assess our vSphere environment. We wanted to get a ball park on how we had to size the VMs. We knew, that we wont need to migrate all VMs. For example our virtual pfSense firewall, the vCenter, the Sophos UTM or our ADFS setup were not planned to migrate.

After the first assessment, we started to play around the the Azure pricing calculator. Just to get an idea on how different VM sizes affect the costs.

Subscription

As a Microsoft partner, we were able to use our internal user rights (IUR) for Microsoft Office 365 and Azure. Microsoft offers us 25 Office 365 E3 plans and a 6000 US-$ budget for Azure (Azure Sponsorship Subscription). Our plan was to stretch the Azure budget over 12 months, so that we don’t have additional costs until we re-apply for our Microsoft partnership. Starting with 6000 US-$ Azure budget, it makes ~16 US-$ per day for our complete Azure deployment.

Sizing

Now, as we knew that we have 16 US-$ per day, we planned our Azure deployment. First of all, we planned the number of VMs. We had 18 VMs on-prem, and we managed to get down to 9 VMs.

two Domain Controller
PKI
Fileserver
Management Server
Remote Desktop Host (all-in-one Deployment)
Ticket System
SQL/ App server
Exchange 2016 for Hybrid Deployment

The View Connection Servers and UAG are still running on-prem. Our virtual pfSense will be moved to a WatchGuard Firebox soon. Sophos UTM and ADFS are gone. A dedicated WSUS server is not necessary any more, we moved back to simple Windows Update and Delivery Optimization.

Instead of D-Series VMs, we decided to go for B-Series VMs. The main reason for this were costs, but today I can say: The performance is quite good. I can’t see any reason for us to move to D-Series.

To connect to our Azure deployment, we had to setup Site-2-Site VPN. We deployed a simple Gen1 Basic SKU VPN Gateway. We had no need for more than 100 Mbit (we’re using a 50/10 VDSL at our office location), BGP or zone redundancy.

Instead of Standard SSD or Premium SSD storage, most of our VMs are using simple Standard HDD storage.

Backups are kept in a Recovery Services Vault with pretty simple polices. Either a VM needs to be current, in this case we keep 7 restore points, or we might need to keep more restore points. In this case we keep 7 daily, 5 weekly, 12 monthly and 3 yearly restore points. And this is only the case for our fileserver.

Additional cost savings

But with this setup we would not get under 16 US-$ a day. :( So we took another approach to break the mark: We shut down VMs at night and at the weekends! It took a bit until my colleagues and I get used to this. Nobody wants to shut down servers without a good reason.

But: We are currently at 18 US-$ per workday, and 10 US-$ for saturday and sunday. Everything, except domain controllers and ticket system, is shutdown at night and on the weekends.

We are using an Automation Account with some simple scripts and schedules to shutdown VMs and start them again.

What’s next?

The next blog post will be around how we planned the usage of Office 365, and how we started with Azure.

Office 365 – Outlook keeps prompting for password

This posting is ~5 years years old. You should keep this in mind. IT is a short living business. This information might be outdated.

This is only a short blog post to document a solution for a very annoying problem. After the automatic update of my Outlook to the latest Office 365 build (version 1809), it has started to prompting for credentials. I’m using Outlook to access a Microsoft Exchange 2016 server (on-premises), without any hybrid configuration. A pretty simple and plain Exchange 2016 on-prem deployment.

I knew, that it has to be related to Office 365, because the Outlook 2016 on my PC at the office was not affected. Only the two Office 365 deployments on my ThinkPad T480s and ThinkPad X250.

To make this long story short: ExcludeExplicitO365Endpoint is the key! You have to add a DWORD under HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover.

HKEY_CURRENT_USER\SOFTWARE\Policies\Microsoft\office\16.0\outlook\autodiscover
DWORD: ExcludeExplicitO365Endpoint
Value = 1

Restart your computer and the annoying credentials prompts are gone.

Stop using your work email for your Microsoft account

This posting is ~6 years years old. You should keep this in mind. IT is a short living business. This information might be outdated.

Microsoft two different logins for their services:

Microsoft Account (former Live ID)
work or school account (Azure AD)

Both are located in different directories. The Microsoft account is located in another user database at Microsoft, as a work or school account. Latter are located in a Azure AD, which is associated with a customer. Both account types are identified using the email address. Microsoft accounts are used for service like Skype, OneDrive, but also for the Microsoft Certified Professional portal. Work or school accounts are mainly used for Office 365 and Azure.

You can use your work email address for your Microsoft account, until someone creates an Azure AD, and a work or school account with the same email address is created. From this point, your login experience with the different Microsoft services will getting worse. The main problem is, that Microsoft tries to find the given account in one of their directories, and it seems that they prefer Azure AD. So the login will work, but the content of the user profile will be different, because it’s a different account.

This is a screenshot from the new login screen. As you can see, there is no way to choose if you wish to login with a work/ school or Microsoft account.

Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

This is the old login experience, where you can choose between work/ school and Microsoft account.

Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

Microsoft calls this an AzureAD and Microsoft account overlap, and they identified this as an issue. As a result, Microsoft denies the creation Microsoft accounts using a work or school email addresses, when the email domain is configured in Azure AD. Microsoft has published a blog post to address this issue: Cleaning up the #AzureAD and Microsoft account overlap

Because of this, you should avoid using your work email address for your personal Microsoft account. Even if this Microsoft account is linked to your MCP/ MCSE certifications. It is not a problem to use your personal Microsoft account, with your personal email address, for your certifications. And it is not a problem to link this account to a Microsoft partner account (as in my case).

Maybe it will be possible to merge Microsoft and work/ school accounts someday. There is an ongoing discussion about this since 2013 (Merge office365 and live accounts that use the same email address).

To remove your work or school email address from your personal Microsoft account, follow the instructions in this support artice (Rename your personal account).