June 3, 2020 at 12:00 am
Comments posted to this topic are about the item Licensing Audit Advice
June 3, 2020 at 2:07 pm
"That might be good advice for life in general: listen more; talk less."
Good advice indeed. Sometimes I'm not as good at that as I should be.
June 3, 2020 at 2:33 pm
I had a much nicer licensing audit that a lot of people I imagine. I was terrified of being audited as I was SURE we were out of compliance but thought when an audit came through, they would catch it. I had brought it up to my supervisor that my interpretation of the licensing terms meant we were violating them, but he said not to worry as we will likely get audited at some point and we are doing our best to be within the licensing terms.
Then the day came of the audit and I was sure I'd be having to explain a bunch of things to the Microsoft Licensing auditor and praying I could talk my way out of it. They sent the IT manager a tool to run which connected to AD and then scraped the network to make sure we had no rogue computers. Then it did a software audit on the machines and packaged it up to send back to Microsoft. Microsoft reviewed it and reviewed what we were licensed for and sent an email back to the IT manager with their observations and asked us to explain a few things.
Most of what they found was easy to explain - our test blades had test versions of SQL installed licensed under MSDN. That one was easy. This also covered our test SSIS and test SSRS servers. So far so good... but then they found our SSRS server. A server which was created ONLY to host SSRS (created before I started, and at this point I was a good 6 years into being a DBA, so the server was likely close to 10 years old). Microsoft told us we needed to move SSRS onto a server licensed with SQL Server OR buy an additional SQL Server license. That was it. No back pay on licensing for 10 years, no fines for running it ulicensed... just a "please move the server or buy a license". At that time, I was not aware that SSRS needed to be on a licensed SQL Server machine. Did not understand that as SSRS requires a SQL Server back end, so I thought it would be more like SSMS. Learned something that day. Well, learned 2 things - also learned how to move SSRS to a new server without losing any reports! I had read how to do it, but had never actually done it at that point.
We also had to buy a few more Office licenses and Windows licenses for desktops, but overall, the Microsoft audit was a lot of stress for nothing.
As long as we are TRYING to meet the spirit of the license, Microsoft seems to be pretty reasonable. The thing to remember is if they come down too hard on you, they may lose you as a customer. If the audit is too intrusive, they may lose you as a customer. The company doing the audit wants to make money off of you, so they are going to do what they can to keep you happy while making money.
The above is all just my opinion on what you should do.
As with all advice you find on a random internet forum - you shouldn't blindly follow it. Always test on a test server to see if there is negative side effects before making changes to live!
I recommend you NEVER run "random code" you found online on any system you care about UNLESS you understand and can verify the code OR you don't care if the code trashes your system.
June 3, 2020 at 4:17 pm
I had a much nicer licensing audit that a lot of people I imagine. I was terrified of being audited as I was SURE we were out of compliance but thought when an audit came through, they would catch it. I had brought it up to my supervisor that my interpretation of the licensing terms meant we were violating them, but he said not to worry as we will likely get audited at some point and we are doing our best to be within the licensing terms.
...
thanks, great to hear your experience. I think MS isn't trying to penalize people. I haven't heard the same stories from ORCL
June 3, 2020 at 5:41 pm
A server which was created ONLY to host SSRS (created before I started, and at this point I was a good 6 years into being a DBA, so the server was likely close to 10 years old). Microsoft told us we needed to move SSRS onto a server licensed with SQL Server OR buy an additional SQL Server license. That was it. No back pay on licensing for 10 years, no fines for running it ulicensed... just a "please move the server or buy a license". At that time, I was not aware that SSRS needed to be on a licensed SQL Server machine. Did not understand that as SSRS requires a SQL Server back end, so I thought it would be more like SSMS. Learned something that day. Well, learned 2 things - also learned how to move SSRS to a new server without losing any reports! I had read how to do it, but had never actually done it at that point.
While I've not (yet) gone through a licensing audit, early on at my current job I would've gotten caught out by this myself. I was under the (mistaken) impression that "hey, we've got a SQL license, it includes SSRS, but I don't see that SSRS needs to be on the same server!" Again, thankfully, that was set up before my time and when we went to new servers I found out I was incorrect in my assumption and fixed it so we'd be compliant going forward.
I'd especially be careful about only answering questions and not being overly talkative and volunteering information.
Yeah, this one's nearly burned me a couple times during our regularly scheduled colonoscopies... I mean our regular security audits. It's way to easy to get going on what seems to be an innocent topic which turns into a "and that's why all our SQL logins have sysadmin on all the SQL Servers" sort of thing (they don't, it's an example!)
June 3, 2020 at 7:00 pm
Mr. Brian Gale wrote:A server which was created ONLY to host SSRS (created before I started, and at this point I was a good 6 years into being a DBA, so the server was likely close to 10 years old). Microsoft told us we needed to move SSRS onto a server licensed with SQL Server OR buy an additional SQL Server license. That was it. No back pay on licensing for 10 years, no fines for running it ulicensed... just a "please move the server or buy a license". At that time, I was not aware that SSRS needed to be on a licensed SQL Server machine. Did not understand that as SSRS requires a SQL Server back end, so I thought it would be more like SSMS. Learned something that day. Well, learned 2 things - also learned how to move SSRS to a new server without losing any reports! I had read how to do it, but had never actually done it at that point.
While I've not (yet) gone through a licensing audit, early on at my current job I would've gotten caught out by this myself. I was under the (mistaken) impression that "hey, we've got a SQL license, it includes SSRS, but I don't see that SSRS needs to be on the same server!" Again, thankfully, that was set up before my time and when we went to new servers I found out I was incorrect in my assumption and fixed it so we'd be compliant going forward.
I'd especially be careful about only answering questions and not being overly talkative and volunteering information.
Yeah, this one's nearly burned me a couple times during our regularly scheduled colonoscopies... I mean our regular security audits. It's way to easy to get going on what seems to be an innocent topic which turns into a "and that's why all our SQL logins have sysadmin on all the SQL Servers" sort of thing (they don't, it's an example!)
hahaha... all SQL logins are sysadmins. I enjoy that. I've gotten into the "show too much info" before when an auditor was sitting beside me one time. They saw that we still had accounts enabled on our OLD domain after we had done our changeover. Old domain was offline, so authentication would fail for any of those, but the auditor asked "why do you still have <old domain> accounts on the SQL instance?". Answered them and didn't go into detail, but just explained why it was still there - we haven't had a chance to remove them yet and wanted to keep them around to ensure all logins were migrated to the new domain with the same permissions.
Strangest request I ever had from an auditor was to run a script which would give them usernames for both windows and sql accounts along with their associated hashed passwords. I told my boss that I didn't feel comfortable giving them passwords (even hashed ones), and would prefer not to give them usernames either. He told me to give them usernames but put NULL in for the passwords because they shouldn't have hashed passwords. Still not thrilled about giving them a list of usernames, but boss said it was fine.
The above is all just my opinion on what you should do.
As with all advice you find on a random internet forum - you shouldn't blindly follow it. Always test on a test server to see if there is negative side effects before making changes to live!
I recommend you NEVER run "random code" you found online on any system you care about UNLESS you understand and can verify the code OR you don't care if the code trashes your system.
June 3, 2020 at 11:26 pm
They saw that we still had accounts enabled on our OLD domain after we had done our changeover. Old domain was offline, so authentication would fail for any of those, but the auditor asked "why do you still have <old domain> accounts on the SQL instance?". Answered them and didn't go into detail, but just explained why it was still there - we haven't had a chance to remove them yet and wanted to keep them around to ensure all logins were migrated to the new domain with the same permissions.
Oh lordy this...
While it's not an item we've gotten called on by auditors, it's one of my pet bugaboos, because NONE of the orgs that utilize our SQL instances TELL US when someone has left (retired, fired, quit, died, moved to another org entirely, or were abducted by aliens.) I usually find out when we migrate to new servers and I'm re-creating the logins and get "No matching account found in domain" sort of errors...
Of course, our current move to a cloud provider means, if someone doesn't work there anymore or shouldn't have access, an account wasn't created for them and being a completely different domain, well...
The logins have gotten cleaned up...
September 8, 2022 at 9:54 am
This was removed by the editor as SPAM
Viewing 9 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply