@Grey said in MS SQL Server 2016 on Windows Server 2019?:

Also https://docs.nethserver.org/en/v7/mssql.html.

yuck lol.

I would not run that any all in one server like Neth.

@thecreaitvone91 said in MS SQL Server 2016 on Windows Server 2019?:

@IRJ said in MS SQL Server 2016 on Windows Server 2019?:

@scottalanmiller said in MS SQL Server 2016 on Windows Server 2019?:

Trying to find this info while on a call. Will SQL Server 2016 happily live on Server 2019? Have an app that won't let us update the database, but I'd prefer to keep at least the OS up to date.

That really makes things expensive. It would be nice to run it on Linux. I would find out if it can support SQL 2017.

Good point, why waste a windows license?

Actually you can: https://docs.microsoft.com/en-us/sql/linux/sql-server-linux-setup?view=sql-server-ver15

YEah but its 2017 not 2016 like I mentioned

@JaredBusch said in Looking to Buy a SAN:

The reason cloud is so expensive for most is because they simply try to move existing workloads to it without redevelopment of the workloads to a server less design.

This is what it really the simple one sentence answer. People think its so expensive because they aren't taking the time to learn the capabilities of cloud environments. It's also not something you can pick up in a single afternoon of reading. You need to do your own IaC deployments and utilize PaaS and SaaS services in addition to IaaS.

The less IaaS you use the better, but if you do need to leverage IaaS you should design it so its scalable and data isnt stored on instances. Spot instances are way cheaper than your typical on demand instances. Up to 90% in certain cases.

That's the reason cloud centered roles are paying $$$ because the value is in the engineering not the operations on the cloud. Operations is automated and OS administration is very, very limited.

After all the pain of the initial design, you get a much more reliable infrastructure that requires MUCH less maintenance.

@scottalanmiller said in MS SQL Server 2016 on Windows Server 2019?:

Trying to find this info while on a call. Will SQL Server 2016 happily live on Server 2019? Have an app that won't let us update the database, but I'd prefer to keep at least the OS up to date.

That really makes things expensive. It would be nice to run it on Linux. I would find out if it can support SQL 2017.

@Dashrender said in encrypted email options?:

@IRJ said in encrypted email options?:

@Dashrender said in encrypted email options?:

Believe me - I'm not in the weeds over Scott's post.

But it's likely that my only requirement is HIPAA, not encryption of data at rest, especially on the patient side, etc.

HIPAA doesn't require encryption at rest, even though I have it on my side with O365.
HIPAA doesn't require encryption at rest on the client side - it makes no mention of it.

You mention authentication to access - does having access to their own email account count? I think it does, so I believe this is checked off.
Is TLS delivery an industry accepted standard - yes, check
Can I bring my own key - not a HIPAA requirement
Will it integrate into my current solution - well, TLS only itself will integrate seamlessly, but domains that don't support it won't fail for 24 hours, leading to complaints of delivery failure and extreme time for notice.

Now I completely agree with your that OME is likely the solution we will employ, if for no other reason that it's what the novice world has come to know as secure/encrypted email.

Actually, one of the things I considering, is - Will management accept the 24 hour delay in notice on failed TLS connections AND do they consider TLS enough to sign off on the HIPAA requirement for secure/encrypted email?
In the past they rescinded the sign off because their family used accounts that didn't support it. Cox has finally moved to a solution that does support it, so that hurdle is removed.

You are all over the place, dude.

If you can get away with doing nothing, should you? Doing the bare minimum is pretty bad, when you know its insecure. You as a customer wouldnt want your PHI handled like that would you?

You're not happy with TLS based delivery of your PHI to gmail? So you don't trust gmail security to keep your email secure? it's encrypted on my side at rest (O365) it's encrypted during transit (TLS) and on your side - that's your problem.

Really, once the patient accesses the data via OME, they're likely downloading it in a non encrypted PDF and saving it to their computer where they're just likely emailing it to someone else.

So I'm asking - what benefit does OME bring to the normal user in this environment?

But let's bump this up to something between you and your lawyer - you trust your email system, you assume they trust theirs, and you're using TLS between them - do you need something more? Are you that worried about the IT person reading the emails? If so, should they be working for you? Or is there a requirement to make it impossible for them to access them?

Believe me guys, I totally get where you guys are going with this stuff. But it sounds like you're saying that TLS alone would never be an option for you, and my question is - why not?

And does that outweigh the onus on the end user when accessing attachments on email?

Phishing. Your work has had email addresses leaked before and an attacker could use this as way to target your patients. An attacker would not use a service that is actively scanning for malware, he would send them via email.

Another advantage is that you control the data until they download. Which means you can set links that expire or remove content at anytime. Could the user have downloaded it, sure. However, you control the full delivery process and can actually remove access at anytime. An email will sit in their inbox forever.

@Dashrender said in encrypted email options?:

@IRJ said in encrypted email options?:

@thecreaitvone91 said in encrypted email options?:

@stacksofplates said in encrypted email options?:

@Obsolesce said in encrypted email options?:

@stacksofplates said in encrypted email options?:

@Dashrender said in encrypted email options?:

HIPAA doesn't require encryption at rest, even though I have it on my side with O365.

I'd rethink that.

https://thehcbiz.com/is-encryption-required-by-hipaa-yes/

So… it’s not required. But HHS goes on:

“The covered entity must decide whether a given addressable implementation specification is a reasonable and appropriate security measure to apply within its particular security framework. For example, a covered entity must implement an addressable implementation specification if it is reasonable and appropriate to do so, and must implement an equivalent alternative if the addressable implementation specification is unreasonable and inappropriate, and there is a reasonable and appropriate alternative.”

The key phrase here is “reasonable and appropriate.” As in, encryption IS required if it’s reasonable and appropriate to encrypt. This is really important and we’ll come back to it later. HHS continues:

“This decision will depend on a variety of factors, such as, among others, the entity’s risk analysis, risk mitigation strategy, what security measures are already in place, and the cost of implementation. The decisions that a covered entity makes regarding addressable specifications must be documented in writing. The written documentation should include the factors considered as well as the results of the risk assessment on which the decision was based.”

Basically what they’re saying is that you don’t “have to” encrypt, but if you choose not to you’d better be prepared to demonstrate, in writing, why you believe that. Then, in the event of an audit, The Office for Civil Rights (OCR) will review your documentation and determine whether or not they agree with you.

IMO, it IS reasonable and appropriate to keep unauthorized people from accessing the data you are sending, which means OME.

Yeah I'm not arguing that. They already have encryption at rest with O365 anyway, I'm saying more everything else. Saying HIPAA doesn't require encryption at rest is I guess technically true, but hopefully you document why it isn't in whatever use case.

It's kinda in the same vein, that you can build a house that meets code, but is still a piece of shit, just because it's the minimum that you have to do by law, doesn't mean that's all you should do, nor does it mean you can't meet the code and still get sued for something you did that met code but done in a negligent way to cause damage later on.

That is a good point. There are set rules you have to follow, but you can also be fired, sued, and in some cases jailed for not doing your due diligence to keep things secure.

This is actually a good example of that, and if you were to say we did the bare minimum because it was slightly easier and less work then you could be liable. Will anything happen other than you being fired, probably not. If you worked for a large organization and you had documented proof of negligence then maybe.

if you have documented proof of negligence, then I'd say you didn't meet some requirement, or the negligence has no baring on the requirements, and as Scott would say - the requirement in that case would be a red herring.

requirements in IT have to be somewhat open-ended because at the rate things are changing. Due Diligence being one of the requirements means you should do what is reasonably required to keep things secure. If there is a large cost involved, then it may be understandable not to pursue more security in a specific area, but if the cost and effort is minimal it is something you should do.

@thecreaitvone91 said in encrypted email options?:

@stacksofplates said in encrypted email options?:

@Obsolesce said in encrypted email options?:

@stacksofplates said in encrypted email options?:

@Dashrender said in encrypted email options?:

HIPAA doesn't require encryption at rest, even though I have it on my side with O365.

I'd rethink that.

https://thehcbiz.com/is-encryption-required-by-hipaa-yes/

So… it’s not required. But HHS goes on:

“The covered entity must decide whether a given addressable implementation specification is a reasonable and appropriate security measure to apply within its particular security framework. For example, a covered entity must implement an addressable implementation specification if it is reasonable and appropriate to do so, and must implement an equivalent alternative if the addressable implementation specification is unreasonable and inappropriate, and there is a reasonable and appropriate alternative.”

The key phrase here is “reasonable and appropriate.” As in, encryption IS required if it’s reasonable and appropriate to encrypt. This is really important and we’ll come back to it later. HHS continues:

“This decision will depend on a variety of factors, such as, among others, the entity’s risk analysis, risk mitigation strategy, what security measures are already in place, and the cost of implementation. The decisions that a covered entity makes regarding addressable specifications must be documented in writing. The written documentation should include the factors considered as well as the results of the risk assessment on which the decision was based.”

Basically what they’re saying is that you don’t “have to” encrypt, but if you choose not to you’d better be prepared to demonstrate, in writing, why you believe that. Then, in the event of an audit, The Office for Civil Rights (OCR) will review your documentation and determine whether or not they agree with you.

IMO, it IS reasonable and appropriate to keep unauthorized people from accessing the data you are sending, which means OME.

Yeah I'm not arguing that. They already have encryption at rest with O365 anyway, I'm saying more everything else. Saying HIPAA doesn't require encryption at rest is I guess technically true, but hopefully you document why it isn't in whatever use case.

It's kinda in the same vein, that you can build a house that meets code, but is still a piece of shit, just because it's the minimum that you have to do by law, doesn't mean that's all you should do, nor does it mean you can't meet the code and still get sued for something you did that met code but done in a negligent way to cause damage later on.

That is a good point. There are set rules you have to follow, but you can also be fired, sued, and in some cases jailed for not doing your due diligence to keep things secure.

This is actually a good example of that, and if you were to say we did the bare minimum because it was slightly easier and less work then you could be liable. Will anything happen other than you being fired, probably not. If you worked for a large organization and you had documented proof of negligence then maybe.

@Dashrender said in encrypted email options?:

Believe me - I'm not in the weeds over Scott's post.

But it's likely that my only requirement is HIPAA, not encryption of data at rest, especially on the patient side, etc.

HIPAA doesn't require encryption at rest, even though I have it on my side with O365.
HIPAA doesn't require encryption at rest on the client side - it makes no mention of it.

You mention authentication to access - does having access to their own email account count? I think it does, so I believe this is checked off.
Is TLS delivery an industry accepted standard - yes, check
Can I bring my own key - not a HIPAA requirement
Will it integrate into my current solution - well, TLS only itself will integrate seamlessly, but domains that don't support it won't fail for 24 hours, leading to complaints of delivery failure and extreme time for notice.

Now I completely agree with your that OME is likely the solution we will employ, if for no other reason that it's what the novice world has come to know as secure/encrypted email.

Actually, one of the things I considering, is - Will management accept the 24 hour delay in notice on failed TLS connections AND do they consider TLS enough to sign off on the HIPAA requirement for secure/encrypted email?
In the past they rescinded the sign off because their family used accounts that didn't support it. Cox has finally moved to a solution that does support it, so that hurdle is removed.

You are all over the place, dude.

If you can get away with doing nothing, should you? Doing the bare minimum is pretty bad, when you know its insecure. You as a customer wouldnt want your PHI handled like that would you?

In your next train of thought you say oh I wonder if OME is even good enough... Of course it is good enough. You have very large organizations with huge compliance departments using it. These organizations get regular audits to ensure compliance.

Your bosses walk all over you, because you bring them stuff like this. You are the IT guy, choose your solution and tell them THIS is what we are doing. You have been in IT a long time man. You should be the one making IT decisions for your organization. Very rarely should your supervisors make these type of technical decisions.

@Dashrender said in encrypted email options?:

Then Scott posts that real secure/encrypted email is basically nothing more more than TLS based transit encrypted delivery.

I wouldn't worry about Scott's definition of things. OME is well accepted as email encryption, even though Scott will argue that it technically isn't. We could get into the weeds about things technically and start an argument that doesnt matter or we could ask ourselves a few important questions.

1.) Is the data actually encrypted?
2.) Is authentication required to access the data?
3.) Is this an accepted industry standard?
4.) Can I bring my own key to ensure no one else can read the data, if I dont trust Microsoft?
5.) Will it easily integrate with my current solution?

The answer to all those is Yes from OME. Why would you setup a more complicated solution just so it can be technically encrypted email? Who gives a shit about the email itself? It is the data you are trying to protect.

No IT department that I have ever seen functions as Scott claims. I have known a few IT people that like to argue about things like this, but in the end they end up wasting time and actually hurting the business. Bringing a more complicated solution in this case solves nothing and only creates issues.

@Dashrender said in encrypted email options?:

I posted this question to my supervisors this morning:

When you hear secure or encrypted email what do you envision? How do you envision that working?

answer 1

Secure or encrypted to me means that the content of the email is protected by a password and is not able to be opened by just anyone. I have several vendors that send me secure mail, so I am used to using it.

answer 2

I think of secure email as a means to send PHI or personal information without worrying that someone who shouldn’t see the information will be able to view it. Encrypted to me means that you need to sign in or have some sort of password to get into the email to view the contents. I may be way off base but….

Why does it matter what your non-IT supervisors think about the definition of encrypted email?

I would say they have a decent grasp of the concept, and who cares if they know the exact definition. It's not their job to know it.

@Dashrender said in Looking to Buy a SAN:

@stacksofplates said in Looking to Buy a SAN:

@Dashrender said in Looking to Buy a SAN:

@thecreaitvone91 said in Looking to Buy a SAN:

@stacksofplates said in Looking to Buy a SAN:

@bnrstnr said in Looking to Buy a SAN:

@Obsolesce said in Looking to Buy a SAN:

@stacksofplates said in Looking to Buy a SAN:

@scottalanmiller said in Looking to Buy a SAN:

@Dashrender said in Looking to Buy a SAN:

@coliver said in Looking to Buy a SAN:

@flaxking said in Looking to Buy a SAN:

@ScottyBoy said in Looking to Buy a SAN:

@flaxking said in Looking to Buy a SAN:

I've recognized an IPOD and witnessed it play out.

In the end the business decided it made more financial sense to put 200 VMs in Azure.

This is for a TV station cloud simply isn't an option to run this stuff unfortunately.

My point is that putting a bunch of VMs in Azure is a pretty expensive solution, but dealing with an IPOD ends up costing the business enough that the cost is acceptable.

The other solution is to not design an IPOD.

Exactly. Buy a correctly sized Scale box - no IPOD... sure, huge upfront cost, but who knows over the long term compared to Azure. etc etc etc.. We don't have any of the other needed information to know if going to Azure was the right move or not... but it's done, so we move on.

Literally everything is cheap compared to Azure. LOL. Even with all their specialty serverless whatever, never seen it cost close to what running your own would do. The cost is just so absurd per workload.

Their serverless offering is on par with the rest. It's a million requests per month and 400,000 seconds of compute for free. After that it's only $0.20 per million executions and $0.000016 per second. That's not really expensive at all.

Exactly. I'm using in a lot of places in production with ~10k users and twice as many devices that is using the serveless functions in many areas... basically for free. And, that's just the start (one example) of it... Having a VM with enough power to process that as frequently as it's getting done now along with all the other benefits around it, there's truly no comparison. Scaling it down to how a typical SMB would use it, well that's a no-brainer, as it'd be totally free and 100% beneficial. I don't think one's ignorance of a technology justifies it's disqualification of use in the real world.

This should probably be it's own topic, but here we are... I'm totally ignorant to Azure and serverless concepts in general. What types of real world services/processes are SMBs using (or could/should be using) serverless Azure for?

There's a few different scenarios. Anything reactionary essentially. Send a message/email based on an event, do some kind of work based on messages in a message queue, transform or modify data, etc. You can even use it to build and define APIs. I have an API running in Vercel (not Azure but another serverless offering) and I don't have to run the service in a VM full time.

Invoicing and Accounts Payable is a big use of it

I don't understand how those are serverless? There is software running - right? where is that software running? This is something I completely don't understand - and I'm guessing @bnrstnr likely doesn't either - but he'll correct me if I'm wrong and he does.

Yes there is a server on the backend but it's abstracted away so you don't see it. The only thing you see is either the JSON payload, the actual HTTP request, or some message queue object. Then you interact with that. It's all run in containers and only spins up when there is a request. So it's not good for very time sensitive requests because you have the latency of spinning up cold containers if there haven't been requests for whatever the timeout period is.

oh man - I'm going going to be made fun of for that bunch of shit I just posted

Actually you asked some fair questions.

There are two concepts to understand with serverless.

1.) It expands dynamically (like a container). Big dogs like AWS and Azure have the ability to basically expand and contract endlessly (elasticity)
2.) The actual function of a service like lambda itself. For example how queuing and messaging work

On my last two jobs I have had no signature at all. I rarely deal with customers, but if I do I want to give them zero information. I am not support, so there is never a reason for them to reach out to me.

@Pete-S said in encrypted email options?:

@scottalanmiller said in encrypted email options?:

That's secure email. That it's transparent makes it even more powerful. My point has been for years - all standard email is fully secure.

You'll get a much higher degree of security when you have real encrypted email and especially so when the email provider doesn't have your private key to decrypt. But then any web mail solution is out.

You can do BYOK (Bring your own key) with OME.

It can use azure key vault storage. So you could even use a hardware module of your choosing that you host and connect to azure.

For your industry and use case, OME or a similar solution is definitely the route you need to go. None of the other options make any sense.

I guess that is the legacy one I was thinking about.

@brandon220 said in Multiple game instances on one monitor:

My FIL is retired and spends most of his time playing Runescape. He has multiple characters and is totally involved in the game. He wants to be able to have at least 3 instances of it running at the same time, but on 1 large monitor where he can "play" them simultaneously.

I am thinking this is entirely possible with some VMs as you can only have 1 instance of the game running at a time on the same PC. The part I am unsure about is how to have the console of each VM running and usable from 1 monitor, mouse, and keyboard.

Does this seem logical versus having 3 separate PC setups going at the same time?

Why not just use a 34 inch widescreen monitor or something? Isnt runescape browser based?

@jt1001001 posted a reasonable and simple solution

@Dashrender said in Recovering SQL Server 2005 Databases:

@IRJ said in Recovering SQL Server 2005 Databases:

@Dashrender said in Recovering SQL Server 2005 Databases:

@IRJ said in Recovering SQL Server 2005 Databases:

I am getting the shakes reading this. I know it's a customer, but fuck I guess their data isn't remotely important to them. I'm surprised it lasted to 2020. Maybe they will learn a valuable lesson from this and not fuck up again this bad.

Good luck this is going to be an annoying task. I would have told the customer good luck as they obviously don't value their data at all! That's not a customer I'd actively choose. This is going to cost them thousands of dollars in support hours. Too bad they didn't migrate 10 years ago when they were supposed to do that.

I guess this brings up another point. At what point do you tell a customer to pound sand? I'm not sure many MSPs or consultants would even take this job.

Not likely. Unless their costs is 10's of thousands of dollars, they'll likely consider it a full on win. They didn't pay for how many new version? they didn't buy how many new versions of Windows? They didn't pay for the manpower do to those upgrades, and now they pay for just over the cost of one, perhaps two of them at once, way later - time value of money and all, they very likely will consider it a win - unless the DB being down is costing them 10's of thousands of dollars.

1. I dont know how many MSPs would even take this work. They were sure lucky to find one.

2. A data breach can cost them the entire business. This isnt just a web server, it is a database server. You work in healthcare and if your company did this and got breached you would be fired and the company would likely shutdown or be severely fined in the millions.

3. Not verifying backups on a database server. Extremely poor execution of system adminsitration. Perhaps it was designed by an engineer 15 years ago and never tested again.

4. I bet you money this isn't VLANed in any way. I bet if one of their workstations get breached, they are fucked city. Who knows maybe they are running Windows XP or Windows 98 on their workstations. We have to assume that is a possibility at this point. Maybe its even internet facing :face_screaming_in_fear:

Even if not directly thinking - oh man we saved so much money by not following those crazy best practices, etc...

Yes and there is no change from shitty behavior

@Dashrender said in Recovering SQL Server 2005 Databases:

@IRJ said in Recovering SQL Server 2005 Databases:

I am getting the shakes reading this. I know it's a customer, but fuck I guess their data isn't remotely important to them. I'm surprised it lasted to 2020. Maybe they will learn a valuable lesson from this and not fuck up again this bad.

Good luck this is going to be an annoying task. I would have told the customer good luck as they obviously don't value their data at all! That's not a customer I'd actively choose. This is going to cost them thousands of dollars in support hours. Too bad they didn't migrate 10 years ago when they were supposed to do that.

I guess this brings up another point. At what point do you tell a customer to pound sand? I'm not sure many MSPs or consultants would even take this job.

Not likely. Unless their costs is 10's of thousands of dollars, they'll likely consider it a full on win. They didn't pay for how many new version? they didn't buy how many new versions of Windows? They didn't pay for the manpower do to those upgrades, and now they pay for just over the cost of one, perhaps two of them at once, way later - time value of money and all, they very likely will consider it a win - unless the DB being down is costing them 10's of thousands of dollars.

1. I dont know how many MSPs would even take this work. They were sure lucky to find one.

2. A data breach can cost them the entire business. This isnt just a web server, it is a database server. You work in healthcare and if your company did this and got breached you would be fired and the company would likely shutdown or be severely fined in the millions.

3. Not verifying backups on a database server. Extremely poor execution of system adminsitration. Perhaps it was designed by an engineer 15 years ago and never tested again.

4. I bet you money this isn't VLANed in any way. I bet if one of their workstations get breached, they are fucked city. Who knows maybe they are running Windows XP or Windows 98 on their workstations. We have to assume that is a possibility at this point. Maybe its even internet facing :face_screaming_in_fear:

I am getting the shakes reading this. I know it's a customer, but fuck I guess their data isn't remotely important to them. I'm surprised it lasted to 2020. Maybe they will learn a valuable lesson from this and not fuck up again this bad.

Good luck this is going to be an annoying task. I would have told the customer good luck as they obviously don't value their data at all! That's not a customer I'd actively choose. This is going to cost them thousands of dollars in support hours. Too bad they didn't migrate 10 years ago when they were supposed to do that.

I guess this brings up another point. At what point do you tell a customer to pound sand? I'm not sure many MSPs or consultants would even take this job.