Sheridan

Ticket was raised, and closed as explained above. I'll have to get another ticket raised with an edited log file so the port 8739 error isn't the focus

Yes, exists on all of the the failing computers that I've checked ESS seem to have dismissed this ticket claiming 8739 is not open and not paid attention to the original error 'Process must exit before requested information can be determined' Its something I've tested a lot recently; 8739 is only open when a user is logged in - which makes sense as the gui loads with a login. The services are running in the background so allow the update to take place whether anyone is logged in or not - so in my case the update has started (and seems to have completed or just about) and then errors out, then also logs an error saying the gui isn't active. I've checked the working computers and they mostly have the 8739 port error as well - because the update was done during the evening when users were logged out! A small percentage have no errors at all and they were computers that had a user logged in (my machine for example) Good luck with anyone's summer 2025 updates, cos it looks like I'm stuck with my issue!

I'm not sure, no one else has reported it on here as far as I can see. However our Solus 3 setup worked fine during the last update so it could just be us!

We're getting the same error on a single deploy as well. I think our Solus is dead 😵

Actually I think the firewall rules are all good, the port 8739 thing is a false flag From my testing the port 8739 is only open when the Solus 3 GUI is active, which is only when someone is logged in - so my updates have worked but failed to tell the UI to inform the logged in user - which seems normal as the gui is separate from the service running that actually pulls down the updates So I'm back to the original error which seems to be the problem: "Process must exit before requested information can be determined." This only happened with the Summer 2025 updates, all worked fine with Spring 2025 and nothing has changed apart from the usual monthly server patches. Its been logged but no response as yet

It looks like its worked and then it fails to connect on port 8739 to report in. Weird as this is (and has been for a while) deployed via GPO What's even odder is when I test connecting to port 8739 from the sims server to a failing one (using TNC) it fails, but if anyone is logged in on that PC then it works! I can't think of anything that would only allow an incoming connection on port 8739 if a user is logged in, that doesn't make much sense to me Also strange is the Client Check from Soolus 3 works even when some isn't logged in - got my head warped this one!

Never got a reply from Support so I worked this out in the end - it was actually hardware failure on an SFP module connecting the primary to the failover unit!

Anyone deployed Summer 2025 yet? We did it tonight and about 20% of the clients showed as successful, the rest failed as one or more errors occurred After panicking a lot, I checked a handful of the failed ones and they had worked, running 7.224 - despite the failure messages in Solus3. Some had failed but this is always the case with Solus3 as we regularly have to fix clients Re-running has the same effect and all are running the same version of Windows 11 and are on 1 of 2 types of hardware so no consistency as far as I can see The error in the client log that failed (but worked!) is PackageRunner: Install failed. Exception: Sims.Solus3.Agent.PackageDeployer.TaskException: Execution of task 2b05c745-cf87-46db-9615-a9bf15631d3e failed. ---> System.InvalidOperationException: Process must exit before requested information can be determined. So my reading of this is that the install hasn't so much failed but hasn't terminated in a timely manner to show the process as complete?

We have an S9 with an older S8 in failover mode, we could access the main S9 on its ip Port 441 and the failover on its heartbeat IP and Port 440 - this was fine until recently (not sure exactly when it started to fail) Now when I try to connect to the failover S8 on its ip:440 I get an error: Service Unavailable The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later. Nothing has changed apart from the recent update that went onto the S9 (Maiden 30) and the smoothwall access rules are the same (haven't changed anything regarding failover since I inherited this setup and I could always previously access the failover S8 this way) Anyone else had issues like this? Just wondering if its the update that's caused this as the S8 is up and running and has been rebooted as well

Its funny, as I looked after SIMS at a previous job for 15 years and never changed it (probably was 2008/2012 or earlier back then) and I've never had to check here until now!

I wonder if changing it on an existing system (I inherited this) from 2016 to 2012 will cause any issues - last thing I need is a corrupt SIMS DB!

We're having lots of issues with Wonde and Classcharts writebacks, delays and just running for long periods. Their solution is to set our SIMS SQL to 2012 Compatibility mode which seems like a backward step The SQL is currently 2016 and is running on a well overspecced server so its not a resource issue Has anyone else done this, it seems like a strange request? Its not something I would change on a live server during working hours anyway but I'm not sure what impact it will have just switching it from 2016 to 2012 mode (and why not 2014 mode!?)

I seem to have the old problem with GPO replication when you see the error 'The sysvol permisions for one or more GPOs on this domain controller are not in sync with the permissions for the GPOs on the Baseline domain controller' and it lists two GPOs which are our Default Domain Controllers Policy and Default Domain Policy Now I haven't seen this error for a while but after some searching I found the old fix where the GPO sometimes had two sets of permissions for the Domain Admins group and you used the following commands to remove and then re-add the permissions: icacls “{GPO UID}” /remove:g “<localdomain>\Domain Admins icacls “{GPO UID}” /grant “<localdomain>\Domain Admins”:(OI)(CI)(F) Now this is where I'm not sure what is wrong, as all three of our DCs have the correct permissions for Domain Admins: i.e Domain Admins:(OI)(CI)(F) However the ones that are failing seem to be missing the extra set of permissions that are on the DCs where it is working, namely: Domain Admins:(OI)(CI)(RX,W,WDAC,WO) So the 'working' DCs have two sets of permissions, and the non working ones just the one (just on these two GPOs though) I've loath to remove any permissions from these as they're both top level - as it might block me from re-adding, but I don't know which set is the correct set to apply?

Done a bit more poking with this and received a lot more detail from the scanning team - it does appear their results show NLA was not enabled across a lot of PCs However I've set up my own test (to replicate theirs almost exactly) and it shows failures as NLA is enabled - even the ones that were failing initially. I've tested this with a linux laptop and rdesktop and also nmap to scan the settings. The GPO was set by my predecessor at the domain level (well - not quite but covers all PCs and laptops!) and doesn't seem to be overidden anywhere or by another policy. Its the sort of policy setting I've had enabled since way back in previous jobs as well So it seems now NLA is enforced but wasn't a few weeks ago when this scan was done. The only thing I can think of is somehow this GPO wasn't applying, or an update flipped the setting and it was flipped back again - I'm grasping here as the scan results are detailed and its been a useful test Looking on the bright side it did find an issue, even if that issue has self corrected somehow!

We've had NLA enforced via GPO for some time (and before my time here as well) and it seems to work, showing as on in the client rdp settings and in the registry as: HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp\UserAuthentication=1 However, a recent security audit has flagged this up as not working, and allowing access to the rdp session without NLA (still need to login though) but its highlighted a possible issue How are you enforcing NLA, is it just via the GPO setting or is there more to it? We've only set this via GPO but its obviously not working 100% as it should

The only red warnings in the console relate to the font errors above. It really doesn't like Chrome this site!

Seems to be working in Edge now and some Chrome but not all! In a couple of cases resetting permissions in Chrome for this site has worked but not all It’s a pretty small issue so people can just use edge for this!

Tried in Chrome with disabled and it makes no difference. They see a whole blank page with nothing on it at all

That's in my allow list, along with a few others I found! But they still see a blank page when they try to explore. Very odd as the logs aren't showing anything Just tried in Edge and that seems to work, but not Chrome! In the Chrome console I just see a load of messages similar to this: The resource https://explore.osmaps.com/fonts/figtree/Figtree-Medium.woff2 was preloaded using link preload but not used within a few seconds from the window's load event. Please make sure it has an appropriate `as` value and it is preloaded intentionally.

We've got some users trying to access Ordnance Survey maps (osmaps.com) and it just doesn't seem to work - I've added all of the urls I can find that relate to it to our Smoothwalls whitelist/https exception/authentication exception rules and they still just see a blank screen when clicking the 'Start Exploring' link on the home page It works outside the school so definitely a filtering issue, but nothing is showing as blocked in the logs so its puzzling Anyone else see this happening with their smoothwall?

I vaguely remember in the past I used the Application Compatibility Toolkit for Windows 10 to get around the message 'do you want to allow this app to make changes whitelist gpo' when running an old unsigned application We have had this crop up for use on a bit of CAD software - but I'm struggling to find the ACT - it seems to be only Windows 10 now Is there a better way (apart from ditching cruddy old software!) to whitelist/shim apps like this?

We ran this patch last week and it seemed to fix the problem, now the same problem is back - are we supposed to just keep running this patch when this re-occurs as its obviously not a proper fix?

Hmm I don't think so but I'll have a search for that thanks

We've been having some fairly regular issues with some clients on our Cisco (ASA) vpn - clients are running 5.1.8.22 The issue seems to be that once connected they may disconnect (which could be down to their home wifi) but the big issue that happens is that they won't reconnect for sometimes over an hour or more I don't think the vpn is the issue as we often have clients connected for days on end, but I did test this and managed to replicate the issue: - Laptop connected to home wifi - connected to VPN no issue - Vpn dropped connected after 30 mins or so and didn't automatically connect - sits in the taskbar with the spinning connection - Many reboots and vpn still won't connect (at the login screen) - the client simply times out or says no network connection despite being connected to the wifi - Switched to another wifi (i.e hotspot) and the vpn connects immediately and things work as normal So it appears if the vpn drops it will not reconnect until the network is changed, but I'm baffled as to what would cause this? Its not just one client as its happened across different ones. Its happened on different hardware as well (both home wifi and laptop) I can't find any configuration on the ASA that would block reconnection on the same connection either - we have reconnection allowed anyway

Have to say this has gone me stumped - I've tried everything I can think of or find, resetting wsus and checking all the folder permissions. I've checked that the server can download .txt files as apparently that's something a proxy can break I guess a new sccm server is on the cards for a summer build!