|
ChubbyThePhat posted:Wew 1903 is finally out. Made a service ring to test on my and a coworker's machines. Obviously not looking to get this in production but hey new stuff! Same, internal test ring wants it already and it's passed my basic "will it install and not gently caress everything up" pass so I'll let them figure out what's wrong with it.
|
#
¿
May 23, 2019 18:15
|
|
|
|
| # ¿ May 13, 2024 22:22 |
|
|
ChubbyThePhat posted:sometimes Cortana decides to gently caress right off I wish Cortana would gently caress off forever
|
|
#
¿
May 23, 2019 18:55
|
|
|
Mr. Clark2 posted:Windows licensing question(s): You want Microsoft 365 E3: https://www.microsoft.com/en-ca/microsoft-365/enterprise/e3?activetab=pivot%3aoverviewtab Your Office 365 would get rolled into the Microsoft 365 package and you'd get all the other stuff you want.
|
|
#
¿
Oct 29, 2020 19:48
|
|
|
The Semi-Annual Channel for Windows Server is also being discontinued with Server 2022 so it’s probably not worth it to look into using it
|
|
#
¿
Aug 13, 2021 05:00
|
|
|
AlternateAccount posted:Aha, thank you. So really, it's Server 2019 that's the primary "full featured' release, and it's getting a proper replacment with 2022? What a weird detour this other business was, then. That's right. 2016, 2019, and the upcoming 2022 are the LTSC versions of Windows Server. The other ones were part of an attempt to use Windows Server for some sort of container stuff and I don't think it caught on enough for them to continue. Windows Server container images are still going to be a thing, but they will be based off 2022 going forward. I think that they are trying to move the Windows Server container stuff to Azure now, where they can manage the updates and such. Those other versions had all sorts of rules like they could only run server core, or something they called Nano Server. Like the other poster said, they had very narrow use cases. e: for reference in terms of Widows Server to Windows 10 feature set mapping: Server 2016 = Windows 10 1607 LTSC Server 2019 = Windows 10 1809 LTSC Server 2022 = Windows 10 21H2 LTSC (supposedly) This is mostly useful to know what the UI looks like and such. Avoid 2016 like the plague if you can since it has the Windows 10 1607 updates servicing which is extremely slow. Number19 fucked around with this message at 20:12 on Aug 13, 2021 |
|
#
¿
Aug 13, 2021 20:06
|
|
|
I have a workstation that absolutely will not apply group policy. C:\Windows\GroupPolicy or whatever is empty and gpupdate fails saying it can’t read the policy from the domain controller despite my being able to browse to the policy in the policy store on all DCs. If I disable the policy it complains about in gpupate another one fails, if I disable that one yet another fails, and so on I’ve decided the computer is haunted and I’m going to wipe it since I’ve wasted more than enough time on it and it’s not that important but I figured I’d pop it in here to see if anyone has an idea about how to get this to work? The only thing I can think of is to remove it from the domain and add it again but given the empty directory I don’t think that’ll do it Any ideas?
|
|
#
¿
Jul 8, 2022 03:29
|
|
|
Yeah that’s where I’m at. I tried for an hour or so and I’ve hit my “it’s faster to rebuild it” threshold It’s legacy anyways so once I get the owners to evacuate any worthwhile data it’s going into the bin E: I might keep it around as a side project to plink around with when I have free time blocks since this kind of thing is exactly what I need to hone and refine troubleshooting skills but there’s no way it’s ever going back into production Number19 fucked around with this message at 05:59 on Jul 8, 2022 |
|
#
¿
Jul 8, 2022 05:57
|
|
|
Number19 posted:I have a workstation that absolutely will not apply group policy. C:\Windows\GroupPolicy or whatever is empty and gpupdate fails saying it can’t read the policy from the domain controller despite my being able to browse to the policy in the policy store on all DCs. I'm bumping this because this has now happened to a few other computers and I'm out of troubleshooting steps. Some new stuff I have discovered:
It's a truly baffling issue and I'd love to know why the gently caress this happens. Google searches have yielded nothing that has helped. I almost want to pay MS for a support ticket but I don't think anyone there will know either. Does anyone have any ideas for poo poo I haven't tried yet?
|
|
#
¿
Nov 28, 2022 22:42
|
|
|
The Fool posted:it's dns op I would have thought that as well but the system account can resolve all the domain and DC FQDNs just fine. e: very specifically when trying to connect to SYSVOL as system, the error returned is: The specified network password is not correct. It's definitely an authentication issue, but I have no idea why
|
|
#
¿
Nov 28, 2022 22:53
|
|
|
Thanks Ants posted:Does the network path between working PCs and broken PCs differ? Some are VPN clients, some are LAN. That was my first guess as well but I had some of each break around the same time. e: to be clear: 2 of the borken ones were in the same VLAN, although they do not share a switch. Each switch's path to the core is identical though
|
|
#
¿
Nov 28, 2022 22:54
|
|
|
Submarine Sandpaper posted:Kerberos works with netbios. I don't know enough to know why when you use the fqdn it is defaulting to ntlm, maybe. The error from the Group Policy client uses the FQDN for policy refreshes: quote:The processing of Group Policy failed. Windows attempted to read the file \\fqdn\SysVol\fqdn\Policies\{39204A9B-B3A0-4C46-AFF1-E7437F41A346}\gpt.ini from a domain controller and was not successful. Group Policy settings may not be applied until this event is resolved. This issue may be transient and could be caused by one or more of the following: where fqdn is the proper value skipdogg posted:What's your imaging process like? Are you sysprep'ing your machines? This would have been done on a fresh out of the box non-imaged machine, like all the others which are not showing this problem. The very first one was imaged using SCCM and was definitely sysprepped
|
|
#
¿
Nov 28, 2022 23:01
|
|
|
Submarine Sandpaper posted:Kill your tickets on a broke and see if you get any on a new attempt. I have purged skipdogg posted:Have you verified all your DNS records for the domain controllers? Make sure there's no old DC information hanging out, and sites and services are setup and up to date. the computer account tickets and that did not help All my records are up to date and I have made sure there are no records for dead DCs anywhere e: i'll setup Wireshark on one of them in a few and see if I can get a capture of wtf is happening Number19 fucked around with this message at 23:22 on Nov 28, 2022 |
|
#
¿
Nov 28, 2022 23:19
|
|
|
The Wireshark at least showed a bit more useful info. I am getting a KRB5KDC_ERR_PREAUTH_FAILED for the computer account policy refresh. I think this eliminates DNS as the fault and seems to confirm what I saw before with the pushd command:quote:C:\WINDOWS\system32>pushd \fq.dn\sysvol Now I need to figure out why the computer account is having Kerberos failures. It definitely seems like the computer password is wrong now somehow, but I've tried a computer account password rotation with no luck. What a bizarre problem.
|
|
#
¿
Nov 29, 2022 00:29
|
|
|
Thanks Ants posted:Does klist show a difference between a working and a non-working machine? No, no scripts to my knowledge. I wouldn't do something like that anyways since it's a Bad Idea. I don't think it's an account lockout issue anyways since \\NETBIOS\sysvol works while \\FQDN\sysvol does not. I think these computers are haunted
|
|
#
¿
Nov 29, 2022 02:16
|
|
|
This has taken an interesting turn this morning. I think I've isolated the "what" here but have no idea as to the "why" or how to fix it. I did a couple more tests and this is not isolated to SYSVOL. It's any DFS path accessed using the FQDN. Using the same methodology to get a command prompt as system, I ran "start \\fqdn\sysvol" and after some time was greeted by an "Enter network credentials" prompt which then has the username of the former workstation user. As in, the computer account is trying to login in using DOMAIN\user.name instead of DOMAIN\COMPUTER_NAME$. On a working workstation, this goes straight through. It really looks like that particular DFS logon path has a bad cached credential. Running the same test for \\DOMAIN\sysvol goes straight through. The question is "how the gently caress did this happen?" and "how do I make it stop doing this?" What a weird fault.
|
|
#
¿
Nov 29, 2022 18:28
|
|
|
Well goons, I have this sorted out. I still don't exactly know the "why" but I have the "what" and the "how to fix" so I'm good for now. So far as I can tell, this is what's been happening:
The fix is to login as the local admin (using the LAPS password), use PSexec to elevate to system, connect to the DFS share (using start \\fdqn\sysvol so it pops up the login prompt), have the user enter their new password (sometimes required twice). This fixes the fault and GPOs update again. I mean...what the gently caress but at least I have a fix.
|
|
#
¿
Nov 29, 2022 19:53
|
|
|
GreenNight posted:Were the DC's patched recently? Been reading about authentication issues with the latest Windows patch. Yes. but I had pre-verified that we would not be affected by the KRB issues. This is definitely some sort of weird race condition or some other stupid poo poo whereby Windows had it set to "only use THESE credentials for delegation" and ones those had changed there was no visible way to update them.
|
|
#
¿
Nov 29, 2022 20:00
|
|
|
If it were that, it would have blown up two weeks ago and also would have been more wide spread. I had this issue happen months ago, well before the patch. I’m pretty sure that’s not the root cause here
|
|
#
¿
Nov 29, 2022 20:12
|
|
|
Thanks Ants posted:Are your DFS namespace servers all healthy? Are the DNS zones for the namespace as they should be? The namespace servers are healthy and DNS works right. This really seems like a case where Windows somehow got configured (or configured itself) for the computer account to access DFS via the FQDN using one explicit set of credentials and then had the computer account get stuck when those credentials were no longer valid. The very first fault I had with this was because the primary user (who's account would have been who's credentials the computer account got stuck like this) was disabled because they left the company. I can definitely fix it now at least but it really should not get stuck like this. I get why it's stuck since the computer account has no way to ask the user to re-authenticate themselves but it really should throw those credentials out and start over if they are obviously broken. We did a password reset wave not too long ago so I expect I will see many more failures as more cached credentials get "stuck" like this. e: also of note, this problem persisted through a domain leave and rejoin to a new computer account object, which seems extra absurd to me
|
|
#
¿
Nov 29, 2022 20:36
|
|
|
To put the capstone on this: the cause here was domain credentials for the FQDN being saved in the computer account's credential manager. Once the password was no longer valid, the computer account was trying to use these cached credentials to access the DFS namespace and failing. By using psexec and deleting that credential, the computer is unstuck and back to working properly. How did those get set for only a few computers? Truly a mystery and not one I plan on trying to figure out right now. It really seems like Windows should not allow this to happen and should definitely fall back to not using those credentials when they don't work.
|
|
#
¿
Nov 29, 2022 22:23
|
|
|
Thanks Ants posted:It sounds like someone's tried to script something in the past and targeted the wrong context That's about all I can guess. The list of affected users has no common thread to them, so I can't figure out what this diverse group would all have done. I think that part of the RCA is going to remain a mystery. If it pops up again I will be able to dig in by tracking recent changes.
|
|
#
¿
Nov 29, 2022 22:33
|
|
|
snackcakes posted:For license assignments I recommend leveraging dynamic AAD groups as much as you can. It's made my life a heck of a lot easier but obviously everyone's environment/requirements are different I just did something like this and it is 100% the way to go. It might take a bit to figure out your rule syntax (the basic rule editor is nearly useless) but one you have a framework in place you suddenly stop having to worry about a lot of things that you did manually before.
|
|
#
¿
Aug 17, 2023 00:16
|
|
|
Glad I caught up on this thread. We have a couple of new laptops which have Optimizer and people were wondering why some Youtube videos sounded strange. Turns out it's Optimizer's "Remove others' background noise" setting. Thanks Dell!
|
|
#
¿
Jan 17, 2024 22:56
|
|
|
|
| # ¿ May 13, 2024 22:22 |
|
|
kiwid posted:Are Yubikey's reusable, as in if the employee leaves I can somehow reassign it to another user? They are, yes. But they are also not all that expensive and we treat them as a consumable. If someone get a Yubikey from us, it's theirs forever. You can't stop them from using it for non-work accounts once they have it so it just becomes a personal item for them and we don't want it back. They are also great and I wish I could get more people to take them. I use them for all my daily and admin accounts and it's so much easier to use.
|
|
#
¿
Mar 27, 2024 22:05
|
|