I ran across an interesting a couple of weeks ago when working with a client. The client has several subsidiaries each with their own vNet. The client had a site to site VPN been the Azure vNets. All traffic was successfully crossing the Azure Site to Site VPN as expected. The sticking point was that a software licensing server running in one of the subsidiaries Azure infrastructure configurations. The software licensing software simply wasn’t working.
We fired up Wireshark on Azure VM which was running the software as well on the Azure VM which was running the licensing software. In Wireshark on the VM running the software, we could see the software trying to talk to the licensing software. On the licensing server, we could see the connection request come in, and we could see the response from the licensing software going back to the client. But we looked on the VM running the software we couldn’t see the packet coming back from the licensing server. So the network traffic was simply getting blocked, somewhere. We didn’t have any network security groups set up, and we didn’t have any software firewalls in place. So nothing should be blocking traffic.
We looked at the response that was coming from the licensing server, and it had the DoNotFragment bit set on the response network packet. Now the sure weird thing is that the packet was only 1430ish bytes in size. So it would have fit within the 1500 byte packet, so there was zero chance of the packet being fragmented. But the bit was being set within the vendor’s software, so we didn’t have any way to remove that flag.
We were able to fix it, by changing from a Site to Site VPN to a peered network connection between the two vNets. Changing the network connection to a peer allowed the software licensing process to work as expected and solved the problem.
So if you have software which requires the DoNotFragment bit in your connection, then an Azure Site to Site VPN isn’t going to work for you. If you are doing everything in Azure a peer can work while a Site to Site VPN doesn’t work.
Billing in Microsoft Azure is a strange beast to get your head around, so it is perfectly normal for questions to come up when moving from Pay As You Go (PAYG) in Azure to Cloud Solution Partner (CSP) billing.
Both Azure PAYG and CSP both bill in arrears, but the time frames that the bill comes out are very different. With a PaTG subscription, Microsoft can generate the invoice up to one month after the usage, which is when they bill your credit card. So for example (using the invoice that I’m looking at right now), an invoice dated August 5, 2020, has usage for the subscription from June 6, 2020, through July 5, 2020. So even if you stopped using the services on July 2, 2020, you’ll still be getting invoiced on August 5th.
What makes the usage of these dates even more strange looking, is the date that the customer is billed is set based on the first subscription that the customer has. So if there are multiple subscriptions each one will have its own usage window, but they will all invoice on the same day. They can make figuring out how the billing breaks down much harder.
Another Subscription for this same customer, also billing on August 5, 2020 was for all usage between June 18, 2020, and July 17, 2020. So again, if the service stopped being used on July 2, 2020, Azure won’t bill for that usage until August 5th.
With CSP billing, the billing is still in arrears, but the time window is much shorter. With a CSP, such as Denny Cherry & Associates Consulting, the billing happens a few days after the end of the month. So in the case of our example, any usage from July 1, 2020, through July 31, 2020, and is then invoiced on about August 5, 2020 (we get our bills between the 5th and the 8th typically, and we work to get them sent out the day we get them).
This can create what appears to be overlap since in this case, the customer got two bills on August 5, 2020. One from Microsoft for the PAYG usage, and one from DCAC for the CSP usage. But the usage dates are what is important here. The PAYG usage is from June 6, 2020 – July 5, 2020, while the CSP usage is from July 1, 2020 – July 31, 2020 (the services were moved from one subscription to another, so only one service is up and running at a time) it’s because the Microsoft billing shows up a month late that it appears at first glance that double billing is happening.
If we look at the first charges for the subscription that can explain some of this. The subscription in question started recording usage on August 5, 2019 – September 4, 2020, but the first invoice wasn’t generated for another month on October 5, 2020; over 2 months after the usage first started on the subscription. So since it took so long to start billing, it makes sense that it will take some time before the billing from Microsoft will finish on the PAYG subscription.
What this means is that in the first month or two while services are being moved from a PAYG subscription to a CSP subscription it’s going to look like double billing is going on, but it isn’t. It’s because the billing dates are very different, and Microsoft is billing about one month after the usage period ends, while the CSP is billing just a couple of days after the usage period ends.
Hopefully, this helps clarify what some people are seeing on their Azure bills as they make the transition from PAYG to CSP. We will of course help you navigate through this as we move clients from PAYG billing to CSP billing.
If you’ve got more questions about this, or you want to move over to a CSP, contact us and we’ll help get the process going.
As we know Microsoft Azure has something like 55 regions currently available. One question that I see come up a lot is, about region placement of resource groups as well as resources. This usually boils down to if a have a resource group that has a region of X, can I put resources within that resource group in region Y? X and Y really don’t matter here, as long as they are different.
The short answer here is yes. The why becomes a little more interesting. The region that resources are configured it is pretty self-explanatory, those resources run in that region. Let’s assume an Azure SQL DB Server that is put in the West US region. That means that the database server will be physically located within the West US region. The public IP Address for that Azure SQL DB server will be hosted in WestUS , the storage for it will be in US West.
When it comes to the location of a resource group, that is simply the location that holds the information about the resource group. This means that you can put a resource group is any region, and you can put resources from any region within this resource group.
The only time that you’ll really care about putting an Azure Resource Group is a different region is if that region has an outage. This will cause you to not be able to create new resources within the resource group until the region comes back online. If the region hosting the resource group goes offline, this will not cause the resources within that resource group to go offline. The only impact that you’ll notice is that you can’t create resources within that resource group (you might also have weird issues starting and stopping resources within that resource group).
Let’s think about our example again. We have a SQL Server in West US and we put that in a resource group that is created is Central US. If Central US goes offline, then the SQL Server in West US stays online. If we wanted to create a new Azure SQL DB Server in the resource group, we won’t be able to. The Azure SQL DB Server would need to be created in a new resource group and when Central US is back online the Azure SQL DB Server that is new could be moved into the Resource Group within Central US.
Hopefully, this helps dispel some of the myths of regions and resource placement.
When I’m RPD’ed into a server, I copy and paste things from my desktop to the server all the time. Be in code that I’ve got saved in a doc on my desktop, or something from a webpage that I want to run when I’m troubleshooting something. With Azure Bastion you don’t have the ability to copy and paste as you don’t have an RDP window open, you’re using a web browser instead.
So how do you copy and paste, then you don’t have that ability? Well, Microsoft has given you a little clipboard editor, so you can see and modify what’s in the Azure VMs clipboard. To access the clipboard, find the two right arrows on the left-hand side of the window. They should be in the middle of the left side fo the browser and they should look something like this.
After you click on the arrows you’ll get a clipboard editor that looks something like this (the text will be different, I happened to be running a DISM command when I wrote this). This editor is on your workstation side, not the VM side so you can paste into this as needed, or copy from it to get text off of the Azure VM to your local workstation. Anything that you put into here will be available when you go into the workstation and paste.
Once you are done editing the clipboard (or copying out or it), simply click anywhere else in the VM to make the editor minimize again.
Getting data into your clipboard is suddenly much easier. Sadly there’s no solution for moving files through the Bastion, so those still need to be moved through something like SharePoint, OneDrive, etc. But this is a huge improvement for managing servers in Azure using the Bastion feature.
As Microsoft MVP’s and Partners as well as VMware experts, we are summoned by companies all over the world to fine-tune and problem-solve the most difficult architecture, infrastructure and network challenges.
And sometimes we’re asked to share what we did, at events like Microsoft’s PASS Summit 2015.
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.