Windows 2019 Slower Than Windows 2012 R2
-
@IRJ said in Windows 2019 Slower Than Windows 2012 R2:
@DustinB3403 said in Windows 2019 Slower Than Windows 2012 R2:
@IRJ said in Windows 2019 Slower Than Windows 2012 R2:
@DustinB3403 said in Windows 2019 Slower Than Windows 2012 R2:
SMBv1 is disabled by default and it could be causing this kind of issue. Being this is a legacy program, that would be where I would look at. Enabling SMBv1 on this 2019 VM and see if the performance issue is addressed.
SMBv2 is supposed to be a bit faster than SMBv1.
Yeah, it is, but the clients have to communicate to the server, realize the server no longer supports SMB1, and then connect via SMB2 or SMB3 if the server supports it.
This is also affected by the "Access" style client/server which may only operate with SMB1 in mind.
With this logic, you should then be disabling SMBv1 on the clients. That is even if your clients still have SMBv1 enabled. They would mean someone hasn't been paying much attention to vulnerabilities over the past 2 years.
Scott migrated a legacy application from 2012 to 2019. That's 7 years of change. Assuming the customer didn't actually update the client software, which was likely developed with SMB1 only in mind.
But I get the argument, in this case I think the client has caused more problems than the protocols used.
-
@scottalanmiller said in Windows 2019 Slower Than Windows 2012 R2:
Moved a client/server app from Windows 2012 R2 physical to Windows 2019 on Hyper-V 2019.
Does the app support 2019? Do they support Virtualization? Something going on with the host? I Virtual networking?
-
@DustinB3403 said in Windows 2019 Slower Than Windows 2012 R2:
@IRJ said in Windows 2019 Slower Than Windows 2012 R2:
@DustinB3403 said in Windows 2019 Slower Than Windows 2012 R2:
@IRJ said in Windows 2019 Slower Than Windows 2012 R2:
@DustinB3403 said in Windows 2019 Slower Than Windows 2012 R2:
SMBv1 is disabled by default and it could be causing this kind of issue. Being this is a legacy program, that would be where I would look at. Enabling SMBv1 on this 2019 VM and see if the performance issue is addressed.
SMBv2 is supposed to be a bit faster than SMBv1.
Yeah, it is, but the clients have to communicate to the server, realize the server no longer supports SMB1, and then connect via SMB2 or SMB3 if the server supports it.
This is also affected by the "Access" style client/server which may only operate with SMB1 in mind.
With this logic, you should then be disabling SMBv1 on the clients. That is even if your clients still have SMBv1 enabled. They would mean someone hasn't been paying much attention to vulnerabilities over the past 2 years.
Scott migrated a legacy application from 2012 to 2019. That's 7 years of change. Assuming the customer didn't actually update the client software, which was likely developed with SMB1 only in mind.
But I get the argument, in this case I think the client has caused more problems than the protocols used.
I just dont think turning SMBv1 is even a consideration anymore in 2019.
-
How much RAM did you give the VM compare to the old setup?
-
@black3dynamite said in Windows 2019 Slower Than Windows 2012 R2:
How much RAM did you give the VM compare to the old setup?
Way too much, lowering that once we are clear to reboot. It has 64GB, using 5GB.
-
@IRJ said in Windows 2019 Slower Than Windows 2012 R2:
@DustinB3403 said in Windows 2019 Slower Than Windows 2012 R2:
@IRJ said in Windows 2019 Slower Than Windows 2012 R2:
@DustinB3403 said in Windows 2019 Slower Than Windows 2012 R2:
@IRJ said in Windows 2019 Slower Than Windows 2012 R2:
@DustinB3403 said in Windows 2019 Slower Than Windows 2012 R2:
SMBv1 is disabled by default and it could be causing this kind of issue. Being this is a legacy program, that would be where I would look at. Enabling SMBv1 on this 2019 VM and see if the performance issue is addressed.
SMBv2 is supposed to be a bit faster than SMBv1.
Yeah, it is, but the clients have to communicate to the server, realize the server no longer supports SMB1, and then connect via SMB2 or SMB3 if the server supports it.
This is also affected by the "Access" style client/server which may only operate with SMB1 in mind.
With this logic, you should then be disabling SMBv1 on the clients. That is even if your clients still have SMBv1 enabled. They would mean someone hasn't been paying much attention to vulnerabilities over the past 2 years.
Scott migrated a legacy application from 2012 to 2019. That's 7 years of change. Assuming the customer didn't actually update the client software, which was likely developed with SMB1 only in mind.
But I get the argument, in this case I think the client has caused more problems than the protocols used.
I just dont think turning SMBv1 is even a consideration anymore in 2019.
PowerShell returned positive for enabling it.
-
@Obsolesce said in Windows 2019 Slower Than Windows 2012 R2:
@scottalanmiller said in Windows 2019 Slower Than Windows 2012 R2:
Moved a client/server app from Windows 2012 R2 physical to Windows 2019 on Hyper-V 2019.
Does the app support 2019? Do they support Virtualization? Something going on with the host? I Virtual networking?
App does, we use 2019 for it regularly. Virtualization too, plus it's just a file so "supporting" things is a weird concept.
-
@DustinB3403 said in Windows 2019 Slower Than Windows 2012 R2:
Scott migrated a legacy application from 2012 to 2019. That's 7 years of change
Only five. 2012 R2 is from 2014.
-
@DustinB3403 said in Windows 2019 Slower Than Windows 2012 R2:
Assuming the customer didn't actually update the client software, which was likely developed with SMB1 only in mind.
the client software is regularly maintained, but not "updated" very much.
-
@scottalanmiller said in Windows 2019 Slower Than Windows 2012 R2:
@DustinB3403 said in Windows 2019 Slower Than Windows 2012 R2:
Scott migrated a legacy application from 2012 to 2019. That's 7 years of change
Only five. 2012 R2 is from 2014.
SMH, 2 years is still a long time.
-
@scottalanmiller said in Windows 2019 Slower Than Windows 2012 R2:
@DustinB3403 said in Windows 2019 Slower Than Windows 2012 R2:
Assuming the customer didn't actually update the client software, which was likely developed with SMB1 only in mind.
the client software is regularly maintained, but not "updated" very much.
So very likely a culprit, do you know what the client software is setup to use?
-
And more to the point did enabling SMB1 resolve the issue?
-
Last question for now, is the client software QuickBooks?
https://media.tenor.com/images/7629d456b68179bebc19e525c8aeb051/tenor.gif
-
@DustinB3403 lol, no, it is not. It is an obscure vertical scheduling package.
-
@DustinB3403 said in Windows 2019 Slower Than Windows 2012 R2:
And more to the point did enabling SMB1 resolve the issue?
Won't know till we get a window to reboot it.
-
@scottalanmiller said in Windows 2019 Slower Than Windows 2012 R2:
@DustinB3403 said in Windows 2019 Slower Than Windows 2012 R2:
And more to the point did enabling SMB1 resolve the issue?
Won't know till we get a window to reboot it.
On SW (emoji's won't work for some reason), a post seems slightly related because it was dealing with SMB shares on 2019.
It linked to MS site for the fix -
It mentioned Disabling RCS on the vswitch and/or the NIC itself.
-
@JaredBusch said in Windows 2019 Slower Than Windows 2012 R2:
You might look at VMQ.. it is supposedly not a problem anymore. but meh...
I would second this -- both at the HOST and inside the VMs (if it's there).
-
What data (not user feedback) do you have from before the migration that you're comparing to now to validate the issue? Knowing this can help identity the issue
-
What windows version is on the client? It's not 10 / 1803 or newer is it?
-
Did you get this resolved?
