Replies

“Since that episode I have always built my own computers and softwared them up myself. The OS goes on its own drive, and then a good quality drive is used for a “D”  drive where all my files are stored. I do not save anything to my OS drive.”

Please elaborate why adding a secondary physical harddrive and using it for storing data prevents dataloss. In thousands of cases I have literally never seen an “empty” OS drive other then because of malware, partitoning errors made by an amateur or hardware failures, all of which a secondary drive holding all of your data is just as vulnerable to. In this particular case a buggy Windows patch removed default user folders residing on the OS drive but, let’s face it, tomorrows buggy Windows patch could target the folders on the D: drive. (In fact, that particular scenario happened in 2015 to users upgrading to W8.1 from W8 vanilla )

The “D” drive is then backed up to an external drive in a portable caddy which can be taken off site if necessary.”

And by doing so you have created a back-up system that is mostly onsite. At any time that the single “external” harddrive is in that tray both the OS drive and the external drive are vulnerable to malware, powerspikes and so forth simultaniously. If the external drive is even onsite in your home you are vulnerable to disasters like flooding, fire and so on.

If you had introduced an extra external harddrive which you would rotate offsite with the “last days” external drive on a daily basis you would have a better backup system altogether, albeit it being quite cumbersome.

What’s up with this deeply rooted fixation on backing up to local media like usb sticks and external harddrives that a lot of home users seem to be adhering to? Why don’t cough up the few dollars a month that an online backup system costs? Apart from having Terrabytes of homemade movies I can’t think of any reason not do go for the offsite online backup route.

I mean, sure feel free to have a local back-up besides the offsite backup if you don’t want to entirely rely on an online backup solutions provider. Most online back-up software for home use worth its salt offers the option  to create a secondary backup on local media like internal harddrives, external harddrives, NAS and so on, anyway.

TLDR: Even as a home user, follow the 3-2-1 backup rule religiously. And if you don’t know what that rule is, google it.

“I do not use “Documents”, “Pictures”, “Music”, or “Videos” or “Download” folders provided by MS in the OS.”

And why don’t you use those folders may I ask?

Not using them provides some real hassle as most of the software out there (Games, Video editing, Labelprinting, Scanners, browsers and so on.) use those folders by deafult to store, find and save data.

Surely every X years those folders might be more vulnerable then user defined folders (Malware, buggy Windows patch) but since you have those folders back-upped  anyway, why bother?

Furthermore, it can be quite hard to remove the default Windows folders you mention on purpose, let alone by accident. May I ask how you have protected your own custom folders for things like documents, music and pictures against accidental deletion?

“I hear what you’re saying, but if that’s the case, why doesn’t the installer attempt a full backup – or at least prompt the user, and help them run it?”

I agree some sort of warning should be nice. On the other hand I find it hard to believe anyone who in 2018 states that they have never heard backing up their files is important, be it a home or an enterprise user.

“That’s what Windows.old was supposed to be. But never was.”

That folder is just for reverting to the older version of the OS. It was never meant for backing up user folder data, nor would that have been the way to achieve it. (For instance: How do you back-up 800 GB of user data on a 1000GB OS drive filled for 85% to a C:\Windows.old folder on the very same harddrive?)

“All in the belief that those are safe on THEIR harddisk in THEIR computer running ‘THEIR’ Windows”

I don’t want to act sarcastic but, really?!

“I am a home user so I have never heard our thought of ransomware, harddrive failures, physical theft of my pc and disasters like flooding and fire. Those dangers have never crossed my mind, nor have I ever heard about them.”

There are literally tons of online backup solutions out there which will backup home user files for pennies. Or at least get those files in the Cloud where there is some data retention. But please, pretty please, don’t play the ignorant card.

anonymous wrote:

I’m wondering if the junction was deleted for the Documents folder that shows in the Navigation bar, and under Libraries. That would make it “appear” that the files have been deleted there, but they actually exist on the hard drive. I was able to create that scenario by intentionally deleting the junction to Documents on my system. One way to find out is to navigate to the path C:\Users\<Your User Name>\Documents in Windows Explorer. If it’s the junction, you will see the files in the path.

The directories are deleted, but only for users who have at one point redirected their user folders (documents, pictures, downloads and so on.) to different folders or have had an older versions of OneDrive do so, with the caveat that the contents of the old folders weren’t moved to the new location.

The latter can be intentional by the end user (I can’t think of any reason why one should answer “no” to the question if one wants to move the contents of the old folder to the new folder after changing the folder location but apparently some users have done so.) or it can be because an older version of OneDrive with the autosave function turned on didn’t move the data to the new folder location in the past.

https://blogs.windows.com/windowsexperience/2018/10/09/updated-version-of-windows-10-october-2018-update-released-to-windows-insiders/

anonymous wrote:

which update needs to be installed on server side to fix this problem ?

only KB4103715 for Windows 2012 R2 ?

Correct, but it might be adviseable to install KB4103725, the may rollup for Server 2012 R2 which also contains KB4103715.

Maybe you would like to know that your RDP communications are secure.

Nope, I have no doubts at all they are.

Maybe you would like to report the problem to the vendor who can fix it, not just in a user-to-user community.

I’d rather spend my scarce time posting on forums like this one where it might actually do some good then trying to pull the dead blue whale that I personally see as a fitting synonym for Microsoft of the accossiated similitudous beach all by myself. I have been there, and have done that. Having created a few (Well, make that a lot.) of my own I have reluctantly come to believe that in order for Microsoft to even state a “known issue” in any of their KBs either a gazillion of little computer people like myself have to sumbit a support ticket or it has to be one posted by a person who signs of with a company name like Dell, in which case miraculously the giant will awake. At the moment a google search for “this could be due to credssp encryption oracle remediation” (Yes, that’s a search within quotation marks.) yields 117.000 results, but sure enough on the kb4103725 page Microsoft still states “Microsoft is not currently aware of any issues with this update.” They must be using Bing, I guess. I have created support cases about demonstrable faults in Office 365, Open License Activation, Onedrive and have seen desired features and improvements by users on the Windows Phone platform reach 400.000 points, still not netting any results sometimes even years later. If one as an individual user or even huge group of individual users want to see a big company do anything with their feedback one should contact companies like Google, not Microsoft. But if you feel the urge to do so, please go ahead, and make sure to also throw in total meltdown and the dissappearing nic issue while your at it, because it seems they still haven’t been completely resolved by these months updates, too.

Maybe they could either confirm that it’s a bug or perhaps identify what is different in your environment that is causing the issue. Seems like if this were a common issue even on non-English versions, we would be hearing more about it. Have you found others who are reporting this?

Stating the caveat that this behaviour (may patched clients rdp-ing into april patched hosts) happens on non-english language systems is because I haven’t yet seen other users experiencing that exact behaviour on the diverse other forums I have visited looking in to this specific problem. That’s actually trying to find a possible explanation why I don’t see a whole lot of other users with exactly that problem. So as far as my gut instincts go, this might be a problem only on non-english systems, not “even on non-English versions” as you seem to conclude. If such is the case, and therefore only a relatively small group of users is affected (We are rare in running non-English servers, only doing so because we used to be big proponents of Terminal Server which users seem to more enjoy in their native language.) submitting a support ticket would prove to be even more futile.

1 user thanked author for this post.

columbia2011

Why would I? All servers where patched with only a few hours of delay. And losing hours instead of minutes was more because I tested a lot because I wanted to know the specifics of the problem.

Summarizing I think I can safely state the May Rollup does contain some errors affecting clients trying to rdp into machines patched to April Rollup level, and I van only hope the information I provide here will help others with the same problem.

Now if only somebody could confirm that this behaviour also occurs RDP-ing into english versions of Servers (and workstations) patched up to April Rollup level… 😉

I can truly confirm that behaviour, as we have experienced and tested said problem from 3 different Windows 10 Pro workgroup machines fully patched to may rollup level RDP-ing into 6 different physical and virtual servers fully patched to april rollup level, both locally and offsite via VPN. Affected servers where on two different geographical locations. Site-2-Site “VPN-ing” from two different geographical locations. Said testing was only out of curiousity though as on the first workstation I encountered the problem I was able to circumvent the problem after less then 15 minutes of “googling” applying the “Encryption Oracle Remediation” setting in GPO Computer Configuration -> Administrative Templates -> System -> Credentials Delegation to value 3 (vulnerable) on said desktop. We have external access to a lot of servers and workstations though, so out of curiousity (After all, this shouldn’t happen.) I made sure to test a lot of different combinations before I patched all servers only hours later.

One caveat: All mentioned servers are non-english versions (dutch) as are all mentioned Windows 10 Pro clients. Furthermore, all servers had NLA enabled, be it through RDP settings on non domain joined machines or by GPO and RDP settings (We like to tick them both) on domain joined machines.

mcbsys wrote:

Thanks for creating an account.

AFAIK, the registry entry will never be created by applying a patch. It’s only created manually or by group policy for overriding default behavior.

Since you were reporting that RDP does not work between patched machines, i.e. the default behavior is not working properly, I was just checking whether somehow the registry entries had been created and were interfering. Apparently not.

What message do you get when you try an RDP connection? Does it specifically refer to CredSSP? In my domain, for example, RDP fails when Network Level Authentication (NLA) is enabled but the server does not properly detect that it is on a domain (instead the network shows as Public or Private). This is a network location awareness issue not directly related to CredSSP.

We received the exact message as in the picture, both RDP-ing into domain machines and/or non domain/workgroup machines (For instance, our Hyper-V hypervisors generally are workgroup members.)

Disabling NLA though via RDP settings on a Server 2012 non domain machine patched to april rollup level gave instant RDP access from may rollup patched windows 10 clients though, as did disabling NLA on Server 2012 domain member servers patched to april rollup patch level.

Edit to insert attachment

1 user thanked author for this post.

columbia2011

I agree with you that Microsoft has provided ample warning of this and in my personal opinion there indeed isn’t a lot wrong with the way they have been securing this protocol in the “careful, documented, multi-month rollout of a mitigation” way as you have described it.

One small caveat though: I can confirm this problem also affects May rollup patched Windows 10 machines RDP-ing into April rollup patched servers. According to the KB that shouldn’t happen. It also presented me (And a lot of other people and Administrators alike I am sure.) with a predictable problem:

-Generally workstations/desktops/notebooks are set to automatically download and install updates. Because of this, they generally have the rollup installed on, or shortly after, patch tuesday.
-Generally server administrators tend to have the Microsoft Update setting set to “Download but let me decide when to install”. This will provide them with a (hopefully short) windows of time to evaluate any major problem with the updates during the days that follow patch tuesday. We, for example, tend to patch our clients servers the first week-end after patch tuesday. This, as proven by a few troublesome updates we have seen over the past few years, isn’t an unwise approach while still not affecting security a whole lot.

And there you have it: Administrators like myself who have to patch a lot of client servers monthly from a remote location patched to a patch level “only one patch tuesday behind” suddenly are unable to RDP into said servers. So the general feeling that seems to be around that this problem only affects “Those naughty administrators that are laggin way behind in their updates” is a little unjustified in my humble opinion. 😉

I can confirm this too. Disabling NLA on the unpatched host will allow patched workstations to connect. Tested with both Server 2008 R2 and Server 2012 hosts and Windows 10 Pro clients. Of course you do need to have physical access to the host in question or an unpatched client or a patched client with GPO Computer Configuration -> Administrative Templates -> System -> Credentials Delegation enabled and set to the setting “vulnerable” as mentioned by me elsewhere in this post to be able to adjust this setting.

Yes, I can confirm that.

de nada..I mean “you’re welcome” 😉

mcbsys wrote:

anonymous, I’d be curious whether the registry entry described in the KB article exists on servers and/or clients and if so, what is its value? But really I’m out of ideas. Please post back on your progress and solution to benefit the community.

I decided to create an account, that should clear some of the confusion as a multitude of messages in this post are of my writing 😉

Registry key HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters

W10 Pro Patched with May Rollup: Not present
W10 Pro Patched with May Rollup: Haven’t been able to tell as all our workstations and the workstation at our clients already have the rollup installed . If I do encounter one I will post back here or, if I find the time, I will revert the update on one to check if the key is present.
Server 2012 Standard without May Rollup: Not present
Server 2012 Standard with May Rollup: Not present

2 users thanked author for this post.

mcbsys, Elly