Month: February 2017

Some Files Not Being Replicated By DFSR

I recently came across a problem within a DFSR replicated folder where some files were not being replicated between the folders. After a bit of checking to make sure the file types were not on the excluded list I concluded that these could be temporary file after seeing this mentioned on a couple of forum threads.
Checking the files in explorer or using attrib.exe did not show any temporary attributes set, however checking with fsutil.exe did show a temporary attribute. The command to run is;

fsutil usn readdata "filename"

When I ran the command I got the following output;

PS L:\> fsutil usn readdata "Camera log.xlsx"
Major Version : 0x3
Minor Version : 0x0
FileRef# : 0x000000000000000000050000000e5dd6
Parent FileRef# : 0x0000000000000000000100000000011a
Usn : 0x00000002c60e7378
Time Stamp : 0x0000000000000000 00:00:00 01/01/1601
Reason : 0x0
Source Info : 0x0
Security Id : 0x0
File Attributes : 0x120
File Name Length : 0x1e
File Name Offset : 0x4c
FileName : Camera log.xlsx

The output here includes the file attributes on the file. The file attributes field is a bitmask that shows exactly what combinations of attributes have been set on the file in question. In my case shown here, 0x120 would be 0x20 (Archive) and 0x100 (Temporary) giving a bitmask of 0x120 for the file attributes.
Microsoft have an “Ask the Directory Services Team” blog post about this, listing all the possible values you can have in the file attributes field, but the short answer is 0x100 is the temporary value and if you’re bitmask includes the temporary attribute, then the file wouldn’t be replicated by DFSR.

If you’re looking to just remove the attributes for the file in question then the following command in PowerShell will do it;
Get-childitem ".\Camera log.xlsx" | ForEach-Object -process {if (($_.attributes -band 0x100) -eq 0x100) {$_.attributes = ($_.attributes -band 0xFEFF)}}

If you want to trawl any subfolders and remove temporary attributesfor more of these then you can use the following
Get-childitem .\ -recurse | ForEach-Object -process {if (($_.attributes -band 0x100) -eq 0x100) {$_.attributes = ($_.attributes -band 0xFEFF)}}

Or if you just want to do this in the current folder, just remove the recurse switch.

Server 2016 & Windows 10 Start Menu Not Working

I’d been having some problems with the start menu in both Server 2016 and Windows 10 stopping working. Googling around revealed various posts and loads of the same advice on how to fix the problem. These included using the Deployment Image Servicing and Management tool with the /restorehealth switch;

DISM /Online /Cleanup-Image /RestoreHealth

Reinstalling all modern apps via PowerShell with the following command;

Get-AppXPackage -AllUsers | Foreach {Add-AppxPackage -DisableDevelopmentMode -Register "$($_.InstallLocation)\AppXManifest.xml"}

Creating a new user account and just using that, not an option if the problem affects all accounts on the machine. The only one of the options mentioned that did help was to re-install Windows, this left the start menu working. However as soon as I domain joined the machine again, it stopped working again after a restart. This led me to look at Group Policy as a potential culprit, and sure enough, moving the object to a separate OU and blocking all policy on it left the start menu working. After a long process of linking policies in one by one I came down to a very specific registry setting.

I’d set the ACLs on a specific registry subkey of HKLM, in this case it was HKLM\Software\Microsoft\RPC. These ACLs were missing one specific entry, namely APPLICATION PACKAGE AUTHORITY\ALL APPLICATION PACKAGES.
Adding this in with only read permissions and forcing a policy update brought the start menu immediately back to life. That ACL is one that has appeared in Server 2012 I think, but since that particular part of our policy predates 2012 that ACL wasn’t there. Oddly enough I’ve not seen this cause any problems with Server 2012/2012 R2/Windows 8/8.1, only with Server 2016 & Windows 10.

So the take away from this is to make sure if you restrict any registry ACLs, make sure you include read access for APPLICATION PACKAGE AUTHORITY\ALL APPLICATION PACKAGES.

If all this was helpful and worked for you, please drop a quick note in the comments.