User Profile
ajm-b
Brass Contributor
Joined 6 years ago
User Widgets
Recent Discussions
Windows print spooler making indecipherable kerberos spn request
I've been looking at eliminating NTLM use in my domain, and noticed that Windows clients' print spooler service is falling back to using NTLM to reach the print server. Digging deeper, it's making a request that I can't decipher at all... "The service principal name (SPN) krbtgt/NT Authority@<my domainfqdn> is not registered, which caused Kerberos authentication to fail: 0x7. Use the setspn command-line tool to register the SPN." Kerberos auth works for everything else in the domain, I'm ONLY seeing this from the print spooler.Getting to the bottom of it: Remote Computer Management\Storage\Disk Management - SOLVED
I just wanted to share a solution to a challenging, poorly documented issue (as far as my research found). 3 parts to allow managing a remote system with Computer Management\Storage\Disk Management: On both systems (one you are trying to manage, and the one you are on), enable firewall rule group Remote Volume Access (I turned on rules only for Domain profile) On both systems (again, one you are using and your target system) need to have Virtual Disk Service started (or at least set to Automatic Startup, I believe default is Manual) On the system YOU (the manager) are on, you probably need to ensure that somehow, someway, the TARGET COMPUTER ACCOUNT (it's DOMAIN computer account) has, on YOUR SYSTEM, the User Logon Right Access this computer from the network. I achieved this by adding the target system to my local system's Remote Desktop Users group, because that and Administrators are the only two groups granted this URA by the "MSFT Windows 10 2020 - Computer" baseline GPO. BOOM! Totally works to a remote system now. In my case, both systems are Windows 10 2004. You probably wouldn't want to add "Domain Computers" permanently to all your IT Techs' PCs as Remote Desktop Users, but you could add them temporarily just when you need to remote disk manage something for a ticket, then remove it. Cheers!Do user licenses affect application of Retention Policy?
I'm really confused on this. Example scenario: Let's say AAD end user John owns a file in OneDrive named "reports". A retention policy is defined for OneDrive to retain everything for x days (the timespan is not important to this question). Do the licenses assigned to John's user (like AAD PP1, 365 A1, etc) affect whether or not the retention policy applies to John's "reports" file?retention / deletion question - exclude long-lived files?
Noob question: I really like the idea of defining a blanket [retain 1 year then delete] policy, but users sometimes have files they legitimately need to keep for longer - how can I exclude those? The data are basically working/reference material I'd want to retain 1 year from creation date... but I don't care about retaining it longer + also don't want to automatically delete it the huge variety of content would be impossible to reliably match by query; only the end user knows "I want to keep this thing indefinitely until I'm done with it" It seems like I could accomplish this with multiple labels/policies but I'm a little hazy on the details. Help?2012 R2 Failover Clustering, SMB v1, SMB Signing, NTLM v1, crashed guests
This is blowing my mind, please help. I've been phasing in group policy to: disable SMBv1 require SMB signing client/server e.g. [ms network client/server...(always) = enabled] 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. 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? 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).
