You are the operator of Azure VMs and must to updates, backups, etc, and test.
You must practice failure scenarios and have processes to deal with it.
DO not use the VM temporary disk
Do not attempt to convert from Standard to Premium disks during DR site failover – the conversion is not instant.
Large VMs do not compensate for application architecture –sometimes refactoring cannot be avoided
Do not had-code specific VM gallery image names into scripts. Images are retired after two years – use the latest version because it is recently patched.
Use DskSpd and FIO to measure performance as early as possible. Run multiple tests – because Azure Cache will kick in to improve performance. Note that some regions (East US) will perform faster than others.
Use WS2019 to capture Azure host maintenance events in the faulover clustering event logs – 1139, 1140, 1136
S2D on Azure IaaS VM guest clusters can only use 2-way and 3-way mirror reliiency types. S2D caching tiers cannot be used.
Don’t let S2D volumes become 100% full. Expanding when they are full is difficult and requires downtime.
S2D is slower on clouds that enforce VM network QoS
Mirror repair is faster on WS2019.
WS2019 for file server roles, especially the Information Worker workload is better.
Microsoft has announced a new preview of a platform-based jumpbox called Azure Bastion for providing secure RDP or SSH connections to virtual machines running or hosted in Azure.
Secure Remote Connections
Most people that are using The Cloud are using virtual machines, and one of the great challenges for them is secure remote access. You need RDP or SSH to be able to run these machines in the real world.
Remember: for 99.9% of customers, servers are not cattle, they are sacred cows.
Just opening up RDP or SSH straight through a public IP address is bad – hopefully you have an NSG in place, but even that’s bad. If you enable Standard Tier Security Center, the alerts will let you know how bad pretty quickly. And if the recent scare about the RDP vulnerability didn’t wake you up to this, then maybe you deserve to have someone else’s bot farm or a bitcoin mine running in your network.
There are ways that you can secure things, but they all have the pluses and minuses.
The real reason that we have point-to-site VPN in Azure virtual network gateway was as an admin entry point to the virtual network.
The clue is in the maximum number of simultaneous connections which is 128, way too low to consider as an end user solution for a Fortune 1000, who Microsoft really do their planning for.
If you have supported end user VPN then you know that it’s right up there with password resets for helpdesk ticket numbers, even with IT people like developers. Don’t go here – it won’t end well.
Just-in-Time VM Access
JIT VM Access is a feature of Security Center Standard Tier. It modifies your NSG rules to deny managed protocols such as RDP/SSH (the deny rules are stupidly made as low priority so they don’t override any allow rules!).
When you need to remote onto a VM, an NSG rule is added for a managed amount of time to allow remote access via the selected protocol from a specific source IP address.
So, if it’s all set up right, you deny remote access to virtual machines most of the time. But you will open direct access. And the way JIT VM Access manages the rules now is wonky, so I would not trust it.
An RDP Jumpbox
This is an old method – a single virtual machine, or maybe a few of them, are made available for direct access. They are isolated into a dedicated subnet. You remote into a jumpbox, and from there, you remote into one of your application/data virtual machines.
Unfortunately, it’s still straight RDP/SSH into a machine that is directly accessible on the Internet. So in the remoting protocol vulnerability scenario, you are still vulnerable at the application layer. You could combine JIT VM Access, but now normal daily operations are going to be a drag and I guarantee you that people will invest time to undermine network security. Also, you are limited to 2 RDS connections per jumpbox without investing in a larger RDS (machines + licensing) solution.
This one is relatively new to me. At first it looked awesome. It’s a HTTPS-based service that allows you to proxy into Linux or Windows virtual machines via RDP or SSH.
All looked good until you started running Windows Server 2016 or later in your virtual machines and you needed NLA for secure connections via RDP. Then it all fell apart. The solution requires you to either disable NLA in the guest OS (boo!) or to hard code a username/password with local logon rights for your guest OS’s into the Guacamole server (double-boo!).
In case you don’t know this, a bastion host is another name for a jumpbox – an isolated machine that you bounce through. In this case, Bastion is a service that is accessible via the Azure Portal. You sign into the portal, click Connect and use the Bastion service to connect to a Linux or Windows virtual machine via SSH/RDP in the Portal. The virtual machine does not require a public IP address or a “NAT rule”, but it’s still SSH/RDP.
On the downside:
There’s no multi-factor authentication (MFA)
It requires that you sign into the Azure Portal – many people running in the guest OS might not even have those rights!
VNet peering is not supported – so larger enterprises are ruled out here … no one in their right mind will deploy 500 bastion hosts (one per VNet) in a large enterprise.
Microsoft did say that these things will be worked on, but when? After GA, which based on the time of year I guess will be just before/after Ignite in early November?
In my opinion, Bastion is the right idea, but more of the backlog should have been included in the minimal viable product.
A Gateway to a Better Solution
If you are a Citrix or a RDS person then you’ve been screaming for the last 5 minutes. Because you’ve been using something for years that most people still don’t know is possible. Both Citrix and RDS have the concept of an SSL gateway.
In the case of RDS, we can deploy one or more (load balanced) Windows Server virtual machines with the RDS Gateway role. If we combine that with NPS and Azure AD, we can also add MFA. With a simple tweak to the Remote Desktop Connection client (MSTSC.EXE), we can RDP to a Windows machine behind the RDS Gateway. The connection from the client to the gateway is pre-authenticated, x.509 certificate protected, HTTPS traffic encapsulating the RDP stream. That connection terminates at the RDS Gateway and then forwards as RDS to the desired Windows Server virtual machine behind it.
Unlike the previous jumpbox solution:
This can be a low-end machine, such as a B-Series.
It can scale out using a load balancer
Many people can relay through a single jumpbox machine.
You won’t need RDS licensing at all, not even to scale out to more than 2 users per gateway machine.
So – there’s no SSH here. So Linux is a problem.
We don’t really have a complete solution right now. Azure Bastion probably will be the best one in the long-run, but it has so many missing features that I couldn’t consider it now. For Windows, an RDS Gateway is probably best, and for Linux, a Guacamole server might be best.
Windows Server 2019 & Hybrid: Windows Admin Center, virtualization, clustering, storage, networking, private cloud, etc
UPDATE: We have enough submissions on Office, Intune, and M365 overviews. We need more on Azure IaaS and Azure PaaS. But we really want sessions on Windows Admin Center, Windows Server 2019, and data protection using Azure Information Protection & Client App Security.
Microsoft is planning to add Storage Replica into the Standard Edition of Windows Server 2019 (WS2019). In case you weren’t paying attention, Windows Server 2016 (WS2016) only has this feature in the Datacenter edition – a large number of us campaigned to get that changed. I personally wrecked the head of Ned Pyle (@NerdPyle) who, when he isn’t tweeting gifs, is a Principal Program Manager in the Microsoft Windows Server High Availability and Storage group – he’s one of the people responsible for the SR feature and he’s the guy who presents it at conferences such as Ignite.
What is SR? It’s volume based replication in Windows Server Failover Clustering. The main idea what to enable replication of LUNs when companies couldn’t afford SAN replication licensing. Some SAN vendors charge a fortune to enable LUN replication for disaster recovery and SR is a solution for this.
A by product of SR is a scenario for smaller businesses. With the death of cluster-in-a-box (manufacturers are focused on larger S2D customers) the small-medium business is left looking for a new way to build a Hyper-V cluster. You can do 2-node S2D clusters but they have single points of failure (4 nodes are required to get over this) and require at least 10 GBE networking. If you use SR, you can create an active/passive 2-node Hyper-V cluster using just internal RAID storage in your Hyper-V hosts. It’s a simpler solution … but it requires Datacenter Edition today, and in the SME & branch office scenario, Datacenter only makes financial sense when there are 13+ VMs per host.
Ned listened to the feedback. I think he had our backs and understood where we were coming from. So SR has been added to WS2019 Standard in the preview program. Microsoft wants telemetry (people to use it) and to give feedback – there’s a survey here. SR in Standard will be limited. Today, those limits are:
SR replicates a single volume instead of an unlimited number of volumes.
Servers can have one partnership instead of an unlimited number of partners.
Volume size limited to 2 TB instead of an unlimited size.
Microsoft really wants feedback on those limitations. If you think those limitations are too low, then TALK NOW. Don’t wait for GA when it is too late. Don’t be the idiot at some event who gives out shite when nothing can be done. ACT NOW.
If you don’t know it, Windows Weekly on the TWiT podcast network, is one of the (if not the) biggest Microsoft news podcast around. I’ve been a listener for a long time, and enjoy the news & conversations between the hosts, with news coming from Mary Jo Foley and Paul Thurrott. Because of my writing on Petri.com, a sister site of Paul’s site, I’ve gotten to meet Paul a few times. Mary Jo and I have talked a few times and met at conferences over the years – she gave me a massive opportunity a few years ago by inviting me to do a guest article on her site while she was on vacation. Both are real journalists using the blogging platform, and they’re the sort of people I respect in the media … and they’re nice people too.
I first met them in person at the TechEd in New Orleans when I was given a press pass. I was sitting out in the press room, and the two megastars of Microsoft news sat across the table from me. I kind of nerded out
Anyway … I’m here at the Ignite conference and Mary Jo and Paul were doing a live recording of Windows Weekly in a studio that Microsoft had set up to do various live community podcasts throughout the week. I’d always thought that I’d love to visit the studio in California when Windows Weekly was on but never had the chance. This was an opportunity to sit in and enjoy the show live instead of in my car while commuting to/from work. I sat in, and it was enjoyable. As usual, the two had some background news and information from interviews with senior Microsoft staff that filled out knowledge that I had.
Often at recording at events, the show opens up an audience mic for Q&A. I think at one point Paul said something about “why is there no Cortana in my country”. After a series of questions where Windows Phone came up, I decided to walk up and offer up something different. It starts at the 1:25:49 mark.
It was very cool to appear, even in a tiny way, on a show that has informed me so much over the news. Thanks Paul & Mary Jo, and to the TWiT network for the opportunity!
Microsoft has just announced that they are splitting Windows Server and System Center into two channels:
Long-Term Servicing Channel (aka Branch)
Long-Term Servicing Channel
This is the program that we’ve been using for years. Going forward, we will get a new version of Windows Server every 2-3 years. This big-bang release is what we are used to. We’ll continue to get 5 years mainstream support and 5 years extended support, and recently Microsoft announced the option to pay for an extra 6 years of Premium Assurance support.
Existing installations of Windows Server will fall into this channel. This channel will continue to get the usual software updates and security updates every month.
This is aimed at hosting companies, private cloud (Azure Stack), and other customers that desire the latest and greatest. In addition to the usual monthly updates, these customers will get an OS upgrade, similar to what happens with Windows 10 now, twice per year in the Spring and Autumn. Each of these releases will have 18 months of support after the initial release. Most of the included features will be rolled up to create future Long-Term Servicing Channel builds. While the Long-Term Servicing Channel releases will probably continue to be named based on years, the Semi-Annual Channel will use build numbers. A theoretical release in September 2017 would be called version 1709, and a March release in 2018 would be called version 1803.
Customers who can avail of this option are:
Software Assurance customers
MSDN and similar programs
SPLA wasn’t mention but this surely would have to be included for hosters?
The first word that came to my mind was “confusion”. Customers will be baffled by all this. MS wants to push out updates to more aggressive customers, but most companies are conservative with servers. The channel had to split. But it shall be fun to explain all of this … over and over … and over … and over … and again.
This is a licensing post. I will not be answering anylicensing questions. If you have any licensing questions then please send them to an account manager at your licensing supplier. No exceptions!
Microsoft has been making quite the fuss about a new benefit of Software Assurance for Windows Server called Azure Hybrid Use Benefit.
Whether you’re moving a few workloads, migrating your datacenter, or deploying new virtual machines (VMs) as part of your hybrid cloud strategy, the Azure Hybrid Use Benefit (HUB) provides big savings as you move to the cloud.
You can make use of this licensing benefit in a few technical ways when deploying VMs in Azure. You can choose the [HUB] images from the Marketplace (manually or via JSON/PowerShell) or you can check a box in the Create Virtual Machine blade:
The implied message is that for every machine you have covered by SA, you can get 40% (or more) savings by being charged for the VM minus the cost of Windows (Linux VM pricing). Well, that’s sort of true. When you dig a little deeper you’ll learn a few things.
Standard Versus Datacenter
The SA benefit of HUB works differently if you have Std or DC licensing. If you have a Windows Server Std license with SA then you can use this benefit when moving the licensed machine to Azure. You’re not getting anything extra here … just the ability to move your license.
If you have Windows Server DC license with SA, then you can use this benefit to deploy additional Windows VM licensing in Azure.
For every 2-processor Windows Server license or Windows Server license with 16-cores covered with Software Assurance, you can run either of the following at the base compute rate:
Up to two machines with up to 8 cores or
One virtual machine with up to 16 cores.
Let’s assume that you have licensed a new host with Windows Server 2016 with SA. That host has 16 cores. From that license we are getting HUB licensing for Windows Server for either:
2 VMs with up to 8 cores each, e.g. a pair of DS2v2s OR
A single VM with up to 16 cores.
If you bought WS2016 Std, then all you get is the ability to move either that physical machine or 2 VMs from that machine (AND decommission the host) to Azure.
If you bought WS2016 DC, then you think “that covers all my VMs”. Yes; it does for on-premises licensing. But HUB still only gives you the above 2 options for the physical host’s license. The VMs don’t have licenses, so you get the same amount of licensing as Std edition, but at least you can keep your on-premises stuff and add new HUB VMs in Azure.
Bigger VMs in Azure
If you need more cores in your Azure VMs then you can stack licenses. You can take 2 on-premises licenses and “stack them” to get 16 + 16 cores for an Azure VM with up to 32 cores.
I haven’t completed a deployment of a HUB VM, so I am not 100% sure of this, but I don’t think that there is anything more than an honour system to this type of licensing. It’s up to you to verify that you have correctly licensed your Azure VMs. Azure is probably the next frontier for licensing auditors, so don’t fall into any easy traps that they can roast you in.
Don’t Buy SA for HUB
Don’t get me wrong, HUB is a nice add-on but it’s not going to make a huge difference for companies with lots of virtualization. It’s a nice perk but it’s not why you attach SA to your hosts. You do that for lots of other reasons, such as Cold Server Back UP Recovery, upgrade rights, adding mobility to OEM licenses, and more.
Got Any Questions?
I won’t be answering them. Please ask an account manager at the supplier of your licensing.
Another thank you, this time to the folks that answered this second survey that focused on Windows Server application servers no matter if they were physical, virtual , on Hyper-V or anything else.
In this survey I asked:
What percentage of your APPLICATION servers run with MinShell or Core UI? Consultants: Please answer with the most common customer scenario.
0% – All of my servers have a FULL UI
40-60% – Around half of my servers have MinShell or Core UI
80-100% – All of my servers have MinShell or Core UI
In other words, I wanted to know what was the market penetration like for non-Full UI installations of Windows Server. I had a gut feeling, but I wanted to know for sure.
I was worried about survey fatigue, and sure enough we had a drop from the amazing 425 responses of the previous survey. But we did have 242 responses:
Once again, we saw a great breakdown from all around the world with the USA representing 25% of the responses.
Once again I recognize that the sample is skewed. Anyone, like you, who reads a blog like this, follows influencers on social media, or regularly attends something like a TechNet/Ignite/community IT pro events is not a regular IT pro. You are more educated and are not 100% representative of the wider audience. I suspect that more of you are using non-Full UI options (Hyper-V Server, MinShell or Core) than in the wider market.
Here we go:
So the vast majority of people are not using any installations of MinShell or Core for their application servers. Nearly 15% have a few Core or MinShell installations and then we get into tiny percentages for the rest of the market.
We can see quite clearly, that despite the evangelizing by Microsoft, the market prefers to deploy valuable servers with a UI that allows management and troubleshooting – not to mention support by Microsoft.
Is there a regional skewing of the data? Yes, to some extent. The USA (25% of responses) has opted to deploy a Full UI slightly less than the rest of the world:
You can see the difference when we compare this to a selection of EU countries including: Great Britain, Germany, Austria, Ireland, The Netherlands, Sweden, Belgium, Denmark, Norway, Slovenia, France and Poland (53% of the survey).
FYI, the 4 responses that indicated that 80-100% of application servers were running MInShell or Core UI came from:
I am slightly less hardline with Full VS Core/MinShell when it comes to application servers than I am with Hyper-V hosts. But, I am not in complete agreement with the Microsoft mantra of Core, Core, Core. I know that when it comes to most LOB apps, even large enterprises have loads of those awful single or dual server installations that right-minded admins dislike – if that’s what devs deploy then there’s little we can do about it. And those are exactly the machines that become sacred cows.
However, in large scale-out apps where servers can be stateless, I can see the benefits of using Core/MinShell … to a limited extent. To be honest, I think Nano would be better when it eventually makes it to a non-infrastructure role.
And we’re back with a follow-up survey. The last time I asked you about your Hyper-V hosts and the results were very interesting. Now I want to know about your Windows Server application servers, be they physical, on VMware, Hyper-V, Azure, AWS, or any other platform. Note: I do not care about any hosts this time – just the application servers that are running Windows Server. Here is the survey:
As before, I’ll run the survey for a few days and then post the results.
Please share this post with colleagues and on social media so we can get a nice big sample from around the world.
As I blogged last night, Microsoft released the technical preview releases for the Threshold generation of Windows Server and System Center, as well as Windows 10. Maybe by now you’ve started your downloads and begun exploring.
Maybe you’d like a little bit of reading to prepare you for what’s to come? Here’s what I could find so far:
What’s New in the Windows Server Technical Preview: The content in this section describes what’s new and changed in Windows Server® Technical Preview. The new features and changes listed here are the ones most likely to have the greatest impact as you work with this release.
Release Notes for System Center Technical Preview: These release notes provide information about System Center Technical Preview. To evaluate System Center Technical Preview, you need to be running Windows Server® Technical Preview and Microsoft SQL Server 2014.
Features removed in System Center Technical Preview: The following is a list of features and functionalities in System Center Technical Preview that have been removed from the product in the current release. This list is subject to change in subsequent releases and may not include every removed feature or functionality.