pete

Short version: If you're using a recently-issued StartSSL cert, it may (read the long version to determine if you're affected) be set as untrusted by Mozilla. If StartSSL/WoSign have been up to more shady activities than already discovered, their roots may be blacklisted for a year and everyone using a WoSign/StartSSL cert will need to get one from somebody else. Long version (Mozilla document): https://docs.google.com/document/d/1C6BlmbeQfn4a9zydVi2UvjBGv6szuSB4sMYUcVrR8vQ/preview El Reg version: Mozilla wants woeful WoSign certs off the list ? The Register

Make sure you go through DNS and amend/delete any entries pointing to the broken DC.

Since putting the September patches on a couple of servers, I've seen failed Veeam backups at the VSS snapshot stage on a couple of servers and today I've had Veeam (I think) snarl up a scheduled patch & reboot of a DC (backup window and reboot/patch windows do not overlap). We've been running Veeam for a while and backup has been pretty flawless until now. Is anyone else seeing anything strange? Currently at the "patch it together and get it running" stage for investigation when our lot have gone home.

Drivers with terrible power saving implementations on the network interfaces (both wired and wireless)? Especially if there's Realtek in them. Turn off WiFi and Ethernet power saving options, see if a gpupdate becomes more reliable. If it does, hunt for better drivers, possibly on the ethernet adaptor manufacturer's website.

Yeah, you need the new version. It's been out for a while, so why Cunninghams haven't offered to upgrade you as part of the yearly maintenance agreement I don't know. I assume the Biostore license is purchased through Cunninghams? I'd speak to them about getting a v3 compatible license from Biostore and then schedule a cut-over time when no-one needs to eat for a couple of hours.

^ Searching through the Avast forums (Avast for Business subforum) reveals that if you already have servers on it, you're grandfathered into support for servers (for current and any new server devices you add). There's an Avast employee posting a "oops, we didn't mean to break that" in a thread where someone is asking about it. I get the impression Avast as a company are rather terrible at communicating information about changes.

^ the "/T" switch in the command line you're using means "trusted", which is short for "the account running this scheduled task has sufficient permissions in SIMS/SQL to query the necessary info in the database". If that's not the case you'll need to specify the SIMS username and password on the command line instead.

a) Dunno, just works *shrugs*. I mean, I was expecting it to be a complete trainwreck based on past faffing but it just worked. b) ID Manager version 3.0.0.6 Bit more info: We have: Cashless server: Biostore Primary Server (source of truth, ID manager talks to this and all secondary servers sync from it.) Biostore Secondary Server (used by vericool cashless catering id station installs) Library system: Biostore secondary (used by MLS id station installs). I've just checked file and reg permissions for Biostore on a finance workstation and I haven't done anything permissions-wise. The one thing that you could check is: When the person first runs ID Manager, are they prompted to enter the server connection info or is it already populated? If it's already populated, it might be pulling it from somewhere they don't have permission to amend. On ours the first time a person runs it on any worksation they're asked to enter it (and thereafter it's saved for them).

We're running it as a scheduled task on the SIMS server, using the "start a program" option, with the command line: DriveLetter:\SQL2012Prod\MSSQL11.SIMS2012\MSSQL\Binn\AutoReports.exe /S:ServerName\InstanceName /D:SIMS /T The "simsscheduledreports" account we're using to run the task has: Membership of a custom SIMS group with "Reports" and "Execute Scheduled Report" permissions (our SIMS accounts are AD-linked). Local admin access on the SIMS server (in order to be able to faff with scheduled tasks - NB: you could probably trim this down, but this is what got it working for us). The task kicks off at 19:00 every day and gets killed if it runs longer the 4 hours (mainly a safeguard against clashing with backup jobs).

Play support agent roulette until you find a competent one, unfortunately. I suspect there's N+1 call centres and some of them don't have updated version of the MS guidance.

^ A standard unprivileged domain user on Windows 7 and Windows 10 has no problems using ID manager. (we don't have any unprivileged machine-local accounts, so I've never had reason to test it)

@timbo343 I've just checked the driver we're using and it's also 1.4.0.1. The 64bit version works on Windows 7 64bit and Windows 10 build 1607 for us without any issues. This is with UareU 4000 series fingerprint readers.

^Yeah, I've seen that. This is "someone or something reset/changed the config in the Avast console". I could understand a typo'd version of what the proxy config should be, but resetting two separate settings templates to 127.0.0.1:8080 is something else. The workstation and the server proxy config on both templates were modified.

Has anyone else experienced the proxy config being reset to 127.0.0.1:8080 by the Avast WebUI? Looking through the configs, the "Default" config is correct, but the customised ones we're actually using have been reset. I have a ticket open (#106176). Oh, and support chat is a premium feature now.......but they haven't announced that anywhere, hence the Avast support person being put on the spot.

@smithson83 Is there a reason you're simply not standing up a fresh SIMS server, testing it with a backup of the database(s) to make sure everythings as it should be and then cutting over in a scheduled maintenance window? Capita don't have a problem with you running a second SIMS server for testing purposes. The downside is if you've got any third-party integration who insist their software is a special snowflake and they need to install it. I've P2V'd and built from scratch. The latter is better from a "less cruft, clear idea of configuration" perspective.

We're using ID Manager 3.0.0.6 on Windows 10 build 1607 without any problems (and no tweaks to user permissions).

Parental controls will handle the application restrictions and (IIRC) a restricted list of websites. Just test it so it behaves as you expect.

OK, So, the fix(es) (which may only apply to HP ProDesk 400 G3s and their particular TPM chip implementation/drivers)...... Main fix: Launch Task Scheduler. Go into Microsoft > Windows > Certificate Services Client and disable the task called "KeyPreGenTask". CPU use should immediately fall dramatically. You may also notice Windows has tried and failed to run the "KeyPreGenTask" task ~3,000 times. Secondary fix: Launch Component Services. Go into Component Services > My Computer > DCOM Config. If you're prompted to register App IDs, do so. Reboot the computer. CPU use should now be sane.

Our lease terms have always been "kit needs to be under warranty for the duration of the lease". I think that's standard for non-shady outfits.

We lease desktops and have done now for several years. We don't lease laptops (accidental damage is too easy). Leasing companies we've used successfully include CHG Meridian, Econocom and HP Financial Services. In terms of service and going above-and-beyond I'd pick CHG out of that lot, but if you're leasing HP kit, HPFS shouldn't be able to be beaten. Pros: IT expenditure year-on-year is easier to plan for. Hardware gets refreshed in a timely manner. Cons: It's a bit more expensive in total. It may not be if you factor into the opportunity cost of less disruption because the hardware's more reliable. Paperwork takes roughly twice as long (extra company involved, more back-and-forth for signatures) and this needs to be remembered if trying to purchase against a time-limited offer. When shipping equipment back, inspect how the courier is planning to do it. If they don't have appropriate packaging, document that (take a few photos of the inside of the van) and proactively inform the leasing company.

I've been using a Sharkoon Fireglider (in black) at home for the last couple of years. No obvious bling bar an illuminated DPI button just after the scroll wheel.

While I have a lovely Model M and some decent Dell Model M clones, they "sound like hippos clog dancing". In the interests of harmony, I need something quieter. Poking around /r/mechanicalkeyboards and other places, I'm torn between a tenkeyless Filco Majestouch-2 or a tenkeyless Ducky Channel One, both with MX Browns. Can you suggest anything else that you use and are happy with? I'm after robust, nice to type on, not much bling, tenkeyless and quiet-ish.

Yup, we get these from time to time. Anyone using unethical marketing tactics is excluded from consideration in future projects.

^ Office 2016 too. My SRP rules are mostly about not allowing random malware to run from user-writable temporary areas, with exceptions for specific legitimate installers. (Yes, I know I should do a default deny + whitelist legitimate things, it's on the list of stuff to do.)

I have a room of ~30 computers. On half of them, my Win 10 1607 curriculum image works without a problem (and also works on a handful of other kit it was tested on). On the other half, it installs fine but sits and grinds as DCOM Server Process Launcher consumes 80>100% CPU and up to 7.5GB of RAM. Leaving it to sit there for an hour doesn't improve matters - it doesn't appear to be a one-time thing. While it might die down (and the PC becomes usable), it'll also ramp up again at some undetermined trigger. Poking around in performance monitoring and selectively disabling services, the bulk of the CPU usage appears to coming from the System Events Broker. BIOS versions are the same across affected / unaffected machines and the hardware is identical (Prodesk 400 G3s). A similar Win 10 1607 lite image (essentially Win10, patches + Office) has worked without problems on 30 identical desktops so far. There's a couple of DCOM 1610 errors in the system log which Google suggests relates to registry permission problems, but they're present on the both the problematic and unaffected desktops. Any ideas? I forsee a morning of sysinternals tools and swearing at murphy.