Recently I was setting up a new phone number queue in Microsoft Teams. As part of this, I was trying to set up a new phone number for the queue. The problem was that every time I tried the Microsoft Teams admin page said that I didn’t have any available phone numbers even though I knew for a fact that I had a phone number current available and set up as a service phone number.
The solution to this was to use the PowerShell cmdlet Set-CsOnlineVoiceApplicationInstance to update the Resource Account with the correct phone number. The problem was that everything online said to connect to SkypeOnline with PowerShell, but nothing every said what needed to get that done. (Yes, this cmdlet is from Skype for Business not Teams, even though this is being done through Teams.)
I was eventually able to piece together what needed to be done.
Skype For Business cmdlet modules aren’t available through install-module. They need to be downloaded and installed from the Microsoft Website.
After the installer is run, open a new PowerShell window in Admin mode.
From there use PowerShell to authenticate and connect to SkypeOnline.
If you don’t have MFA configured use the following PowerShell code.
Now keep in mind that I’m using a US Phone number here, hence the +1. If you are in another country your country code will be different. Whatever the phone number that you have available as a service phone number is the phone number that you enter here.
Once this cmdlet was done the phone number listed was allocated to the resource account, and the phone number was setup and ready to go.
SQL Server Agent is probably one of the least loved, but most used components in Microsoft SQL Server today.
As applications go it hasn’t really gotten any sort of upgrade in probably 20 years, at least I can’t really think of any changes since SQL 2005 was released, maybe even SQL 2000. And that does show just how solid it really is.
The SQL Server Agent just sits there and does its job without any real love or attention. That really is a testament to the work that was done on the SQL Server Agent back in the day that nothing has really needed to be done to it in the last 15-20 years. So for this I say, “Well done Product Team, well done”.
It can be used for job scheduling, alert notification when resources utilization is high, etc.
Microsoft SQL Server has a much-maligned performance monitoring (perfmon) counter called Page Life Expectancy (PLE). What this counter monitors is how long SQL Server will expect to keep your data in memory.
Now it’s true that looking at this monitor right after the SQL Server has been restarted is kind of pointless. This is because when SQL Server starts up, the PLE should increase one value for every second that passes until the cache is completely full. This what we would expect it to do, as the PLE counter doesn’t know anything from before SQL Server was started. And since it has no historical information to work off of. So given that, it knows that SQL Server was started 10 seconds ago, so the PLE needs to be 10 seconds. One second after that, it’ll be 11 seconds, because again that’s all the information that the SQL Server instance has to work with. So when should we be looking at PLE?
The first time that we want to be monitoring PLE is to get a baseline for what we expect this counter should be reporting. If we don’t know what the baseline data is then we don’t know if a problem happens when the value changes.
When the value changes dramatically
The PLE value doesn’t have a target number that we watch for. What we are looking for with changes to PLE are changes to the baseline (see above). When PLE drastically changes is that drop normal, or is that something that is out of the ordinary? If PLE for the server is normally 5,000 and it drops to 65, is that drop normal or is it something that we need to look at?
One of the things we can do with PLE is look for trends. If the PLE drops every morning at 3am, then we need to see what’s happening at 3am that is causing the SQL Serer to flush the buffer pool each night at 3am.
NUMA Node Imbalance
PLE is tracked at the instance level, but this is just the result of a math formula. The actual raw PLE number is gathered at the NUMA node level. If we look at the NUMA node level PLE values and compare them to each other we can see potential imbalances between the NUMA nodes, and we can dive into those imbalances and see why SQL Server is doing that. Maybe we have a server configuration issue that needs to be addressed? Maybe we need to change the soft-NUMA settings for the server?
PLE Doesn’t Give Answers
As we’ve seen PLE doesn’t give answers. Instead, PLE points you in a direction and is one of the diagnostic tools that can be used to see that there is a problem that needs to be investigated and identified. PLE doesn’t specifically tell you what the problem is. It tells you that there is a problem and that the problem needs to be investigated.
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 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.