-
Posts
147 -
Joined
-
Last visited
Content Type
Forums
News
20th
EduGeek EDIT Conference
Blogs
Everything posted by NetworkServices
-
It was one of the Local Policies/User Rights Assignment. Unfortunately I can't remember which one it was. We'd been stripping back policies that had been in place since the domain was 2003 and many were no longer applicable or recommended. Whilst most of them reverted to local defaults when the policy was changed to not configured, one of them reverted to nothing applied at all.
-
Yep fixed. At ease, everyone.
-
Two physicals and one VM. To be honest I think I may be on to a solution and have now got one of the DCs back again. It probably wasn't the update that caused it but a local security policy balls-up. The update and subsequent reboot caused the symptoms to appear so I may have unfairly blamed the update when in fact it was all my own fault! Just need a window of opportunity to reboot the other two to see if they come back after the policy correction.
-
Good morning EduGeekers, Did anybody experience any issues with Server 2022 domain controllers after the March update (KB5078766)? Our three domain controllers installed this update and rebooted as scheduled on Sunday. However when I examined them on Monday morning, all three of them were constantly sitting at the "spinning dots" part of booting. The servers appear to be actually working (replicating/servicing clients etc) behind the scenes and from an end user perspective there appears to be nothing wrong. If we try to RDP into any of them we can authenticate but just receive a black screen so really only can do anything from a remote command line. Rebooting hasn't made any difference. Seems very strange to me that this affected all domain controllers yet the same update installed on member servers didn't cause an issue. Any ideas on anything I could try? They exhibit the same behaviour when booting into safe mode too which is odd to say the least. Many thanks.
-
If it's just Windows 11 WiFi clients try disabling Credential Guard. There is a gpo for it (although I can't see it for looking at the moment). I had the same problem and disabling this solved it. EDIT: I think it was called 'Turn on Virtualization Based Security'. This was the one I disabled.
-
Have you tried disabling BPDU guard on the switch port? no spanning-tree bpdu-protection
-
I'm afraid that I couldn't recommend Lightspeed. All the time they supplied an on site server things worked reasonably well. Ours died last year and was told that they no longer support on site servers and that the alternative was Lightspeed Relay which is cloud based. The irritating thing about this is that all workstations now require a piece of client software installed to facilitate this and this is where the elephant in the corner manifests. Firstly, this set up doesn't work with anybody running a BYOD scheme. If you can't install the client on these devices then all will receive unfiltered access. Secondly, the client upgrade process is particularly cumbersome. An MSI is provided which makes deployment easy enough but it requires a password in order to uninstall before a new version can be installed. If you previously deployed via GPO and then set the policy to remove the client in order for the upgraded client to be installed, all workstations will then stall on "removing managed software" as it's obviously waiting for the removal password to be entered which of course you cannot do from this point. Thirdly, the client seems to work fine for web browsers but if you have other software that requires access to the Internet, access can be quite hit and miss. We've had serious issues with the Relay blocking access to exam software and even our finance software. You then have to go through this convoluted process of enabling a debug mode in order to get to the bottom of it. It is the above mentioned problems that are prompting us to look for alternatives.
-
Quite possibly. However you'd have weigh up the acceptable level of risk by performing this registry modification. For us there are only three workstations on site that share their local printer so applying this to only those three machines was deemed acceptable. It wasn't necessary to apply it to all clients on the network. There are other critical fixes included in KB500565 so uninstalling this was something that I preferred to avoid if possible.
-
Weirdly this issue has only affected our users who share their printers from their workstations rather than our main fleet of printers that are shared from a server. The "Cannot connect to printer" message was popping up on any machine that tried to connect to the printer share. Removing KB5005565 from the workstation that shares the printer seemed to do the trick but as I am not keen on leaving machines unpatched I discovered that I could leave KB5005565 in place and modify the registry instead. Adding the following key and then restarting the spooler service allowed other workstations to connect to the shared printer... HKLM\System\CurrentControlSet\Control\Print "RpcAuthnLevelPrivacyEnabled"=dword:00000000
-
Something I thought about this morning for those of you who use staff local profiles. Ensure the retention date is sufficiently long. Assuming schools may be shut for months the last thing any of us want is to return to find that the cached profiles have been purged. Whilst this may not be too much of a problem I'm thinking specifically about maybe Finance/Admin staff who use bespoke software that would be a pain to set up again should the profile disappear.
-
Coronavirus: General discussion (see opening post for rules)
NetworkServices replied to Dos_Box's topic in General Chat
Just gone on there to reset a password for someone here and their site is currently unavailable. -
Coronavirus: General discussion (see opening post for rules)
NetworkServices replied to Dos_Box's topic in General Chat
Aren't they only supposed to be focusing on serious crimes? -
We don't install either here. As I recall we've only had one person request Java because of some archaic site in the last couple of years. The vulnerabilities were promptly explained and they found an alternative site that didn't require it.
-
Good. I was just ensuring that others interpreted those points in the same manner as I did. There's always somebody somewhere that insists anything that receives power from the mains in any fashion is subject to portable appliance testing.
-
Would this include our particular type of UPSs? Ours don't plug into standard 13A sockets. They are permanently cabled with that thick armoured type cable that gets used on electric ovens.
-
PAT testing is for portable devices. Since it takes three people to lift our UPSs I don't consider them portable.
-
Thanks for the heads-up, Arthur. I got so used to not having an official MSI from Mozilla for such a long time I gave up checking with them directly. I'll be sure to use that when I push out the next upgrade. Probably next week.
-
Not had any bother with it. In fact it seems to be the most stable browser out of the ones we use. FrontMotion create MSIs for deployment and there are ADMX templates available for all of the group policy stuff.
-
Firefox as default here with the option of Edge/Chrome and for those that know where to look IE.
-
I'll catch up with our Chrome users at some point today. They've been quiet since yesterday but I'm guessing they've all switched to an alternate browser for the time being.
-
Describes the symptoms perfectly.
-
Very similar although in our case the new tabs remain white too. Only once minimized and then maximized does it appear to return to normal. However as soon as you refresh or attempt to go elsewhere it goes white again.
-
Tried that already, unfortunately.
-
Thanks all for the responses. I'll keep an eye on the bug report. Hopefully it will get resolved soon.
