Windows 2019 Slower Than Windows 2012 R2
-
trying....
Enable-WindowsOptionalFeature -Online -FeatureName smb1protocol -
Disable Windows....
-
You might look at VMQ.. it is supposedly not a problem anymore. but meh...
-
-
-
@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.
-
-
@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.
-
@Alex-Jones said in Windows 2019 Slower Than Windows 2012 R2:
https://community.nodebb.org/topic/11484/nodebb-now-with-gif-support
I will probably get that privilege revoked. I tend to abuse gifs.
-
@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.
-
@scottalanmiller how is speed outside of the app or process in question?
Can you check file transfer speed via smb3 from Win10 to unc path on server?
-
@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.
