Replies

CraigS26 wrote:

Does the above Note mean the article is irrelevant to those of us who don’t have it?

No, it only means that if the key is missing, the default value of “0” (zero) is assumed by the OS.

For Vista, Win 7, Win 8.x and Win 10 this key is valid.  Works for Home, Pro and Enterprise editions.  Also valid for Server 2008, 2008 R2, SBS 2011, Server 2012, 2012 R2 and Server 2016.

If it does not exist, and you want to change the behavior as described in CH100’s excellent overview, you can add the key.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters

Create a new DWORD at that location.  Name it precisely DisabledComponents . . .  caps matter in the registry!

Assign the value you want to force TCPIPv6 behavior as described.

Cheers!

 

Edited: because spelling . . .

~ Group "Weekend" ~

2 users thanked author for this post.

CraigS26, ch100

Some of my clients are very small:  5 to 10 users/workstations and a single server running everything network.  These are the SMB’s that have relied for years on the ‘Pro” edition to meet their needs.  I’m researching how to best support Windows 10 Pro for them.  There are – as you and others here have helped identify . . . some odd issues.  They are also the companies that have the hardest time justifying budget for a recurring cost subscription.  (Recurring costs are the bane of variable – and often slim – budgets for most SMB’s.)

Some are . . . larger.  For them running Enterprise is not a problem, and the support/management tools I need to do justice for them work nicely in Win10ENT.

And a shout-out to both of you:  knowingly or not this discussion has produced some positive results.  Thanks!  🙂

~ Group "Weekend" ~

2 users thanked author for this post.

ch100, PhotM

While direct REG key modification is very powerful, the problem is that they are often unsupported and can be (as you recently discovered) a moving target.

I do use them from time to time, and am currently investigating the suggestions you gave in the Tools forum.  But whenever possible, I much prefer GPO for my large client networks.  It’s generally stable for long term use, it’s supported by Microsoft (which is important to us), and we don’t have to worry as much about slight differences in the client versions and patch status.

Also I saw earlier a question by you about the long term survival of GPO.  I can tell you with a very high level of confidence that – at least on SMB and ENT domains – Group Policy is alive and doing well.  It will be so for the foreseeable future under Server 2012 R2 and Server 2016 and beyond. And even though it’s a bit less than it used to be, local GP on Windows 10 Pro in stand alone or peer to peer mode will also be around for the foreseeable future.

 

~ Group "Weekend" ~

I wish all the major affected sites would prominently post this disclosure – positive or negative – on their landing pages.

Thank you!

~ Group "Weekend" ~

1 user thanked author for this post.

PhotM

Yep, I tend to be a bit cautious on these types of reports – even when (and sometimes especially when) they agree with a stance I take with my clients.  Self serving reports only damage the perception of what for some companies is legitimate advice.

I do think – strongly – that end users in a corporate environment should not run as admin on their workstations.  I also provide a special domain  account that’s granted admin on all workstations – but not on the domain – for them to use when they need to update something legitimately.

At the same time, a well trained end user with a clear understanding of what risky behavior to avoid and with good technical mitigations in place can be perfectly fine running as admin.

And training . . . much training . . .

~ Group "Weekend" ~

2 users thanked author for this post.

Noel Carboni, ch100

ch100 wrote:

Registry keys changes should be used only for fine-tuning the product, but not for implementing in Pro functionality which is available only in Enterprise, because this is not guaranteed to work in the future and there would be no warning or documentation about such functionality change.

 

This is my fear as well, which is why I would wish that the lost functionality in Pro be restored.  In particular relating to updates ( which horse I have beat to death by now, to no avail.)  WSUS has it’s own high maintenance needs – the care and feeding of WSUS is not trivial and it’s definitely not “set and forget.”  But even so, that’s preferable to the mess that un-managed patching can do to a critical system.

We do push some reg keys out, but generally only for older – stable – features.  But even then it requires more babysitting over time, and yes – it’s happened that a patch will break our settings.

MS supported GPO settings are by far the preferred method for long term use.

 

~ Group "Weekend" ~

This is why we test GPO settings and reg key pushes to client workstations from the DC before live deployment.  🙂

Yes there can be unexpected side effects from indiscriminate use of GPO on a domain, but this feature gives us a rich management ability to set custom aspects that our clients want and need, as well as the ability to lock down certain vulnerabilities that expose clients to malware (as only one part of a multi-part approach to malware mitigation.)

We use GPO to turn off features we don’t want on the corporate network, turn on features in a consistent manner, set certain defaults so all users only have to learn one method, create file share mappings, push shared printer drivers to every user with presets that make sense for their work process (this last is especially helpful with plotters and loaded paper role types, sizes, color quality settings etc.)

This greatly reduces the time needed to setup a new user profile, or a new machine, and makes it very easy to push out new devices to every machine (like a printer upgrade or a new share.)

We also use it to turn off AutoPlay and in some cases restrict USB usage to authorized use (on compatible hardware.)

Just a few of the many uses we find for GPO on a large network.

~ Group "Weekend" ~

Some of the “lost” GPO settings for 1607 Pro look like they can be set via these keys.  I have begun testing on a domain controller to see if pushing direct REG keys to clients can overcome the intentional limitations on GP.

I’ll try to remember to post results here – might be a few days.

~ Group "Weekend" ~

Some of the problems, like lost control over Windows Updates reboot scheduling, can be retained with AD GPO’s on Windows 10 Enterprise. My gripe is that we used to get GPO settings in Windows Pro that were like enough that SMB’s could keep control. That’s been lost as of 1607.

And for a SMB to get Windows 10 Enterprise they have to subscribe to it, a recurring cost, unless they buy enough Open License seats to meet a minimum.

~ Group "Weekend" ~

I would be very interested in this program if . . . IF . . . they give us a private fast track channel for SMB and small enterprise relevant feedback that would rise above the noise in the normal Feedback Hub. (Note that large enterprises have a fast track reporting and resolution system already – so this program is either being expanded from that, or it’s not for them.)

Case in point: It took Microsoft months to notice a nasty bug being reported by IT professionals about a search related crash in client-side File Explorer when creating folders on server side shares. Once they noticed, they took months longer to raise the priority on the bug because they felt it was a one-off case (it wasn’t – in fact it turned out to be universal for the specific combination of Win 10 1607 combined with Server 2012 R2 on a domain.)

~ Group "Weekend" ~

1 user thanked author for this post.

PhotM

b wrote:

NetDef wrote:

Never – ever – grant your MSA local admin permissions on your workstation.

Why?

I should have clarified more, since part of my original topic was about malware prevention using standard versus admin level user accounts.

My advice about not granting a MSA account local admin permissions (with some exceptions if you are a Microsoft ring tester) is based on the fact that as admin – MSA allows anyone that might compromise your online account total access to your machine – including the right to remotely access things. I’ve personally seen this happen exactly once, but still – it burned. That episode happened when someone enabled the remote file access feature through One Drive, and their MSA was a local admin account, and their MSA was hacked. The ID thief logged onto that machine and extracted saved banking passwords from the victims browser using Nirsoft tools. They were also able to add a system startup malware entry because as admin, they had access to parts of the C: drive that a standard user would not.

There were so many other mistakes made that led to this, but you hopefully get the reasoning behind my advice.

~ Group "Weekend" ~

1 user thanked author for this post.

Elly

rc primak wrote:

Another approach is to create a separate User Account which is always a MS Account login, but only use that Account when using Cloud-centric apps or other activities which require the use of the MS Account.

I forgot I do this too . . . for precisely the same reasons you outlined. Good catch!

~ Group "Weekend" ~

1 user thanked author for this post.

rc primak

For home / small office workstations I take this a few steps further.

1) On new setup: Create a local Admin account. Finish setup and install your base applications and AV, etc.

2) Now create your user account as a LOCAL account, with Standard user permissions (NOT admin!)

3) Repeat step 2 as needed for adult family members that need their own accounts.

4) If you must, convert your account to a MSA. I leave that decision to the reader but I largely agree with the advice given by Woody and Paul T.

5) If you have children, and want to use Microsoft Family Safety, then you need to convert the child’s local account to a MSA. No way around this, and the benefits for this specific use case may be worth it to you as parent.

Never – ever – grant your MSA local admin permissions on your workstation.

Edit: The exception to the above warning: if you must be on a preview/slow/fast ring on a test machine. You are committed to giving the MSA admin privileges. I would not advise that on a production machine.

The primary reason to start with a local Admin account (and create your real user accounts as a Standard User) is this is one of the very best ways to mitigate potential drive by malware drops.

Some rules: don’t surf the net nor open email from the Admin account you create. Think twice if you are ever prompted for that admin accounts password when you do not expect it. If you are browsing the net, reading email, opening an attachment or a document and you see that password request . . . you know it’s time to close all applications and run a virus scan.

And if your standard user account profile gets a non-admin level infection it’s really easy to clean that up from the Admin account. Unless you fall for the prompt that asked for an admin password the infection won’t get root access.

~ Group "Weekend" ~

4 users thanked author for this post.

Elly, Kirsty, rc primak, AlexEiffel

If my theory turns out to be correct (a show stopping bug in the patch for SMB 2) then that would impact all current OS patches.

Security roll-up would include it, so would the Monthly roll-up.

I suspect that we’ll see updates for Feb 2017 within the week. It’s going to throw my schedule off. Sigh . . .

~ Group "Weekend" ~

Just my personal opinion/speculation:

1) Roll-ups cannot be separated anymore, not even by the QA teams at Microsoft. They must be tested as one monolithic patch, and thus it all fails or all succeeds before sign-off.

2) If just one patch fails, but with low system repercussions, they would likely pass the roll-up for that month.

3) But if a patch fails in a way that spectacularly causes major grief for (enterprise systems) or (servers) or (large subsets of current hardware builds) then the entire roll-up is held back.

4) We anticipate (hopefully) one specific upcoming patch that is at the very heart of file transfers on a LAN. The SMB vulnerability. The SMB component has been a major pain in the past; changing it has broken file sharing from devices (scanning printers for example) and older clients. It’s also been a source of file lock contention grief in mixed environments (newer plus older clients and servers).

Getting that wrong in any way could be disastrous for file / data integrity for even very small networks.

~ Group "Weekend" ~

1 user thanked author for this post.

WildBill