Replies

I also work in California. I interpret the wiretapping law as applying to audio, not video. So I use video cameras that do not have microphones. Has anyone heard of someone trying to apply the wiretapping law to silent photos/videos shot either in public places or in my own private residence or place of business?

One client would like to also be able to have an audio intercom in addition to video. Here I’d assume they are okay if it is not recording audio, but just providing a way to communicate in real time with the person(s) who are on camera.

As you probably know, KB3177467 is a new update with the same number. They even changed the Title to start with “2018-10”.

Are you on WSUS? When did you approve KB3177467?

My non-WSUS Win7 machine installed KB3177467 on Oct. 11. Interesting that that was one day after installing the 2018-10 rollup KB4462923.

Yesterday , I pulled an old Win7 machine off the shelf to go back into service. It tried and failed to install the 2017-12  rollup (KB4054518), then installed KB3177467, and now is offering  2018-10 rollup KB4462923.

So it’s unclear if KB3177467 is, or wasn’t but is now, a prerequisite for the 2018-10 rollup. It does seem to be going on automatically for me though.

3 users thanked author for this post.

cesmart4125, Mr. Natural, Microfix

Speaking of severe action, how going back to employing a separate group of in-house software testers rather than relying exclusively on this release-and-see-what-blows-up approach?

3 users thanked author for this post.

GoneToPlaid, Noel Carboni, HiFlyer

I usually use my phone as a hotspot when I need Wi-Fi in a public place. But soon I’ll be vacationing at an Air B&B … do I trust their Wi-Fi? Hmm… I guess I could bring my own router/hotspot to connect to their cable/DSL modem while I’m there…

Please tell me Check for Updates does not override deferral policies now. I’m pretty sure it has been respecting them.

Here’s a PowerShell script to list settings and, optionally, updates:

https://www.mcbsys.com/blog/2015/03/updated-powershell-script-to-show-windows-update-settings/

But it might be easier (and GUI-er) to just run wushowhide (you don’t have to hide anything):

https://support.microsoft.com/en-us/help/3073930

 

2 users thanked author for this post.

Karlston, Great Lake Bunyip

A day later, it shows that the last check was yesterday but now has a Download button:

When I click download, it immediately errors out and offers Retry:

After clicking Retry, it looks for updates and reverts back to “Pending download” with the last check updated to just now:

I have two small WSUS sites. One has had no sync failures this week. The other had a couple failures on Sept. 22 but the third (automatic sync) on Sept. 22 was successful. Looking back, both have been able to sync at least once a day since Sept. 10; once in a while, they have to try two or three times on the same day before a successful sync.

On two small WSUS servers, I see sync failures Sept. 6-9, all successful starting Sept. 10.

My personal notation is to use MM/DD/YYYY or the German DD.MM.YYYY. But for public communication, spelling out the month is best.

As for YYMM, I first learned that as a programmer. When you sort YYYYMMDD alphabetically, it comes out chronologically. Very handy for file and folder names. Your digital camera probably uses that naming convention too.

Great info, thanks. Sounds like July 10, 2018 is the golden date for 1803.

With a 120-day deferral, that puts me at November 7:

https://www.timeanddate.com/date/dateadded.html?m1=7&d1=10&y1=2018&type=add&ad=120

Thanks for digging those up.

There is in fact an August 28 post in which @PKCano says:

“My suspicion is that the “defer = 365” has nothing to do with when you set it on the PC and everything to do with when MS declares the feature update ready for business (ie CBB/SAC/whatever it is next version instead of CB/SACT).”

To which @woody replied, “I believe that’s the case, but still haven’t seen any official confirmation.”

So apparently as of three days ago, no one here knows.

I think this qualifies for a “low transparency” rating on Susan’s Pinocchio score!

Original blog post:

https://blogs.msdn.microsoft.com/sqlreleaseservices/issue-with-security-update-for-the-remote-code-execution-vulnerability-in-sql-server-2016-sp2-cu-august-14-2018/

1 user thanked author for this post.

woody

It’s possible that your issue is patch-related (uninstalling July patches should tell you) but certificate setup is a classic Essentials stumbling block. You might get more help in a forum dedicated to Essentials:

https://social.technet.microsoft.com/Forums/windowsserver/en-US/home?forum=winserveressentials

https://www.server-essentials.com/community/discussions

Up through yesterday, the only July cumulative update offered by WU for Server 2016 was KB4338814, so I finally applied that to all machines. Today, each machine is offered KB4345418. That’s an extra 1.2GB download, an extra 30-60 minutes, and an extra reboot for each server. In other words, installing KB4338814 was a waste of time because it’s (finally) superseded by KB4345418.

Sure wish I understood the rhyme and reason of how/when updates are offered on WU.

In case anyone is interested, here’s how I do it on an Ubuntu/Bitnami distribution running Apache as the web server. I created a custom certbot_renew.sh:

/usr/lib/certbot/certbot-auto renew --post-hook "/opt/bitnami/ctlscript.sh restart apache"

Here’s my cron job:

SHELL="/bin/bash"
MAILTO="my@email.com"
5 10 * * * /opt/bitnami/apps/admin/scripts/certbot_renew.sh

Email is sent through sSMTP (after I installed it).

NOTE Sometimes (probably when “officially” installed via apt-get), certbot also creates its own cron job as /etc/cron.d/certbot that runs twice per day. If that job handles the renewal, because it doesn’t include the hook to restart Apache, the old cert will continue to be served. Restart Apache to load the new cert (sudo /opt/bitnami/ctlscript.sh restart apache), then rename /etc/cron.d/certbot to certbot.disabled.