Home

2012 R2 Failover Clustering, SMB v1, SMB Signing, NTLM v1, crashed guests

%3CLINGO-SUB%20id%3D%22lingo-sub-742949%22%20slang%3D%22en-US%22%3E2012%20R2%20Failover%20Clustering%2C%20SMB%20v1%2C%20SMB%20Signing%2C%20NTLM%20v1%2C%20crashed%20guests%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-742949%22%20slang%3D%22en-US%22%3E%3CP%3EThis%20is%20blowing%20my%20mind%2C%20please%20help.%3C%2FP%3E%3CP%3EI've%20been%20phasing%20in%20group%20policy%20to%3A%3C%2FP%3E%3COL%3E%3CLI%3Edisable%20SMBv1%3C%2FLI%3E%3CLI%3Erequire%20SMB%20signing%20client%2Fserver%20e.g.%20%5Bms%20network%20client%2Fserver...(always)%20%3D%20enabled%5D%3C%2FLI%3E%3CLI%3Erequire%20ntlm%20v2%20only%2C%20reject%20ntlm%20v1%20(same%20settings%20as%20current%20MSFT%20baselines)%3C%2FLI%3E%3C%2FOL%3E%3CP%3EI've%20phased%20this%20trio%20onto%20everything%20else%20in%20our%20environment%20with%20no%20problem%20-%20clients%2C%20member%20servers%2C%20DC's%3A%20everything%20was%2Fis%20working%20fine.%20%3CSTRONG%3EHowever%3C%2FSTRONG%3Ewhen%20I%20applied%20this%20same%20set%20of%20group%20policy%20on%20one%20of%20our%20WS%202012%20R2%20Hyper-V%20nodes%20in%20our%202-node%20failover%20cluster%2C%2010%20different%20VM's%20crashed%20at%20the%20guest%20level%20seeming%20to%20think%20their%20disk(s)%20were%20surprise%20removed%20and%20the%20other%20node%20took%20over%20driver's%20seat%20on%20the%20CSV%2C%20those%20VM's%20were%20automatically%20started%20but%20*some*%20got%20a%20boot%20failure%3B%20manually%20stopping%2Fstarting%20them%20got%20them%20to%20boot%20normally%20with%20no%20observed%20issues.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3COL%3E%3CLI%3E%3CSTRONG%3EWhy%20did%20this%20happen-%20and%20why%20only%20these%2010%20random%20VM's%2C%20which%20weren't%20even%20ALL%20the%20VM's%20on%20that%20node%20at%20the%20time%20the%20change%20was%20applied%3F%3C%2FSTRONG%3E%3C%2FLI%3E%3CLI%3E%3CSTRONG%3EWhy%20did%20these%20changes%20make%20the%20CSV%20coordinator%20be%20moved%20to%20another%20node%3F%20This%20is%20DAS%20shared%20storage%20(Dell%20MD1400)%20over%20HBA%20in%20Storage%20Spaces.%3C%2FSTRONG%3E%3C%2FLI%3E%3C%2FOL%3E%3CP%3EAny%20insight%20you%20can%20provide%20would%20be%20helpful%2C%20I'm%20totally%20stumped%20and%20I%20*really*%20need%20to%20get%20this%20policy%20set%20applied%20for%20security%20reasons%20in%20light%20of%20vulnerabilities%2Fbest%20practice%20recommendations%20that%20came%20to%20light%20after%20patches%20last%20month%20(month%206%20in%202019).%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-LABS%20id%3D%22lingo-labs-742949%22%20slang%3D%22en-US%22%3E%3CLINGO-LABEL%3EActive%20Directory%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3EClustering%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3EHyper-V%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3EStorage%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3EWindows%20Server%3C%2FLINGO-LABEL%3E%3C%2FLINGO-LABS%3E
ajm-b
Occasional Contributor

This is blowing my mind, please help.

I've been phasing in group policy to:

  1. disable SMBv1
  2. require SMB signing client/server e.g. [ms network client/server...(always) = enabled]
  3. require ntlm v2 only, reject ntlm v1 (same settings as current MSFT baselines)

I've phased this trio onto everything else in our environment with no problem - clients, member servers, DC's: everything was/is working fine. However when I applied this same set of group policy on one of our WS 2012 R2 Hyper-V nodes in our 2-node failover cluster, 10 different VM's crashed at the guest level seeming to think their disk(s) were surprise removed and the other node took over driver's seat on the CSV, those VM's were automatically started but *some* got a boot failure; manually stopping/starting them got them to boot normally with no observed issues.

 

  1. Why did this happen- and why only these 10 random VM's, which weren't even ALL the VM's on that node at the time the change was applied?
  2. Why did these changes make the CSV coordinator be moved to another node? This is DAS shared storage (Dell MD1400) over HBA in Storage Spaces.

Any insight you can provide would be helpful, I'm totally stumped and I *really* need to get this policy set applied for security reasons in light of vulnerabilities/best practice recommendations that came to light after patches last month (month 6 in 2019).

Related Conversations
Tabs and Dark Mode
cjc2112 in Discussions on
35 Replies
Extentions Synchronization
Deleted in Discussions on
3 Replies
flashing a white screen while open new tab
Deleted in Discussions on
14 Replies
Stable version of Edge insider browser
HotCakeX in Discussions on
35 Replies