DMcCoy

Check the event logs for any errors during making a shadow copy, if windows cannot complete it in time (due to load etc) it will simply delete all shadow copies. It's also possible that block changes are so large, that the quota only has enough space for the previous version.

Oh, and do remember it's only going to start helping once the machine policy has been applied, so it's still going to happen sometimes until everything has applied the new policy or updated their redirection paths (it should only happen to a user once due to the redirection path update).

All it's supposed to do is create a file in the new location, and if it sees it in both, it updates the registry paths without moving the files. There shouldn't be any major issues as long as machines are later than Win 7, or Win 7 that are mostly up to date. There are some minor issues that there was a hotfix for, but I guess it can't be worse than deleting folders on login!

This UNC change will be the issue, the path is stored for the redirection in two ways for the same location. The updating from one to the other will cause the deletion you are seeing. The policy to prevent this is under Computer -> Windows Components -> File Explorer -> "Verify old and new Folder Redirection targets point to the same share before redirecting" Test it, but it should be what you want in this instance to stop it removing the files. This is the description: This policy setting allows you to prevent data loss when you change the target location for Folder Redirection, and the new and old targets point to the same network share, but have different network paths. If you enable this policy setting, Folder Redirection creates a temporary file in the old location in order to verify that new and old locations point to the same network share. If both new and old locations point to the same share, the target path is updated and files are not copied or deleted. The temporary file is deleted. If you disable or do not configure this policy setting, Folder Redirection does not create a temporary file and functions as if both new and old locations point to different shares when their network paths are different. Note: If the paths point to different network shares, this policy setting is not required. If the paths point to the same network share, any data contained in the redirected folders is deleted if this policy setting is not enabled.

Do you have move enabled for folder redirection? Are you changing between dfs/unc/fqdn paths that are actually the same location? There is an issue when if the redirected folder is actually the same place, but windows sees it with two different paths in the redirection, the move operation will just delete the folder. There is a gpo option to help with this if it is the issue: Verify old and new Folder Redirection targets point to the same share before redirecting. Don't just turn it on though, it needs some testing first to make sure everything else is ok.

That's what I did, but it only works on the first go, with a drive with no partitions (or new vhd/diskpart clean). All subsequent attempts see the MDT scripts messing the order up and using the recovery partition as the installation location. It's an MDT script issue with initial drive letter assignment for WinPE things.

As an aside, I've found MDT terrible at partitioning things. I got the perfect layout for W10 + recovery etc in the proper order. Only works on a blank drive! Run MDT a second time and it falls over due to trying to install a second time to the wrong partition. At least you don't have to create VMDKs and VHDs in a special way now to align the sectors to an 8k boundary along with all yours LUNs!

Do you have group policy preference printers? are they set to replace/update rather than just create? I had lots of Word crashing issues when printers were removed/recreated during policy processing. I fixed it incidentally without knowing and only later was it suggested in a very lonely thread on a MS forum!

Seeing as remoteapp is just "log in to windows server, capture the selected window" then it's just going to be based on the login time to the server. I'm assuming this is a 2012 r2 server or similar. No doubt mandatory profiles from a workstation won't be quite compatible with the server, some apps etc will need to provision again. I tend to use local profiles only for RDS servers.

As of last year (not using it here now) one of the major clinical systems was still using a FoxPro database, you had to have SMB v1.0 for that!

No, this is an expired certificate in the chain, it expired this morning. Affects IE too

There's a status page? Be nice if it was linked from segfl somewhere.

How helpful! Support line says they are "investigating the issue". Looks quite clear to me!

What is the internet connection download/upload speed? How are the users accessing the remote server? Which ISP?

Is this updating a redirection? Does the user profile contain a redirection already? Later versions of Windows sometimes require access to both the old location and the new location to update the registry paths. The event log should record what it thinks it is setting the redirection to. Also %HOMESHARE% is usually \\server\share\userfolder while %HOMEPATH% is usually \ You can user %HOMESHARE%%HOMEPATH%Documents or %HOMESHARE%\Documents to achieve the same effect, %HOMESHARE%%HOMEPATH% can fail in a less useful manner than %HOMESHARE%\Documents if the user doesn't have a home folder set in AD