DFSR.Exe Version Doesn't Match in PowerShell & GUI Properties File Version.

When I look at the DFSR EXE Properties via the GUI

Right Click - Version I am seeing Version: 6.3.9600.18040

Which IS what I am expecting to see since it was recently updated.

However when I run this via PowerShell on the Local DC I am seeing the old version 6.3.9600.16384 -

 PS C:\Windows\system32> Get-Item $env:windir\system32\dfsrs.exe | format-list -Property * 


PSPath            : Microsoft.PowerShell.Core\FileSystem::C:\Windows\system32\dfsrs.exe 
PSParentPath      : Microsoft.PowerShell.Core\FileSystem::C:\Windows\system32 
PSChildName       : dfsrs.exe 
PSDrive           : C 
PSProvider        : Microsoft.PowerShell.Core\FileSystem 
PSIsContainer     : False 
VersionInfo       : File:             C:\Windows\system32\dfsrs.exe 
                    InternalName:     dfsr.exe 
                    OriginalFilename: dfsr.exe.mui 
                    FileVersion:      6.3.9600.16384 (winblue_rtm.130821-1623) 
                    FileDescription:  Distributed File System Replication 
                    Product:          Microsoft® Windows® Operating System 
                    ProductVersion:   6.3.9600.16384 
Name              : dfsrs.exe 

I have been able to replicate this with NotePad.exe

IF I do a “normal” Get-Item it is showing the wrong FileVersion

PS F:\> Get-Item -Path C:\Windows\system32\NotePad.exe | FL *


PSPath            : Microsoft.PowerShell.Core\FileSystem::C:\Windows\system32\NotePad.exe
PSParentPath      : Microsoft.PowerShell.Core\FileSystem::C:\Windows\system32
PSChildName       : NotePad.exe
PSDrive           : C
PSProvider        : Microsoft.PowerShell.Core\FileSystem
PSIsContainer     : False
VersionInfo       : File:             C:\Windows\system32\NotePad.exe
                    InternalName:     Notepad
                    OriginalFilename: NOTEPAD.EXE.MUI
                    FileVersion:      6.1.7600.16385 (win7_rtm.090713-1255)
                    FileDescription:  Notepad
                    Product:          Microsoft® Windows® Operating System
                    ProductVersion:   6.1.7600.16385
                    Debug:            False
                    Patched:          False
                    PreRelease:       False
                    PrivateBuild:     False
                    SpecialBuild:     False
                    Language:         English (United States)

BaseName          : NotePad
Mode              : -a---
Name              : NotePad.exe
DirectoryName     : C:\Windows\system32
Directory         : C:\Windows\system32
IsReadOnly        : False
Exists            : True
FullName          : C:\Windows\system32\NotePad.exe

Note that ProductPrivatePart & FilePrivatePart are not shown.

Using this method I CAN see those properties -

$VER = Get-ChildItem -Path C:\Windows\system32\NotePad.exe -Recurse | Get-ItemProperty | Select -ExpandProperty VersionInfo


PS C:\WINDOWS\system32> $VER | FL *


Comments           :
CompanyName        : Microsoft Corporation
FileBuildPart      : 7601
FileDescription    : Notepad
FileMajorPart      : 6
FileMinorPart      : 1
FileName           : C:\Windows\system32\notepad.exe
FilePrivatePart    : 18917
FileVersion        : 6.1.7600.16385 (win7_rtm.090713-1255)
InternalName       : Notepad
IsDebug            : False
IsPatched          : False
IsPrivateBuild     : False
IsPreRelease       : False
IsSpecialBuild     : False
Language           : English (United States)
LegalCopyright     : © Microsoft Corporation. All rights reserved.
LegalTrademarks    :
OriginalFilename   : NOTEPAD.EXE.MUI
PrivateBuild       :
ProductBuildPart   : 7601
ProductMajorPart   : 6
ProductMinorPart   : 1
ProductName        : Microsoft® Windows® Operating System
ProductPrivatePart : 18917
ProductVersion     : 6.1.7600.16385
SpecialBuild       :



PS C:\WINDOWS\system32> $VER.ProductPrivatePart

18917

PS C:\WINDOWS\system32>

Has anyone else ran into this?

Is this a Bug?

Is there a good work around since I need to check this on several remotes servers…?

I’m hesitant to call it a bug because PowerShell’s just querying NTFS to get that information; if there’s a bug, it’s unlikely to be a PowerShell bug per se. Problem is, I don’t know how the GUI gets its information, or where from.

Do you have any Cmd.exe tools you could run to see what they produce?

This link is similar to what we are seeing.

How to (correctly) check file versions with PowerShell
http://blogs.technet.com/b/askpfeplat/archive/2014/12/08/how-to-correctly-check-file-versions-with-powershell.aspx

I have tried adding the example when using Invoke-Command since it need to be in each session for each remote server -

$Computers = 'ServerA','ServerB','ServerC'

Foreach($Computer in $Computers) {INvoke-Command -Computername $Computer (Update-TypeData -TypeName System.Io.FileInfo -MemberType ScriptProperty -MemberName FileVersionUpdated -Value New-Object System.Version -ArgumentList @(
$this.VersionInfo.FileMajorPart
$this.VersionInfo.FileMinorPart
$this.VersionInfo.FileBuildPart
$this.VersionInfo.FilePrivatePart))
Get-ChildItem "C:\Windows\System32\NotePad.exe" -Force |  FL -Property *version*,@{Name='ServerName';Expression={$Computer}}}

Which is “sort of” working but am getting an error for each server -

Update-TypeData : A positional parameter cannot be found that accepts argument 'System.Version'.
At line:1 char:75
+ Foreach($Computer in $Computers) {INvoke-Command -Computername $Computer (Update ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidArgument: (:) [Update-TypeData], ParameterBindingException
    + FullyQualifiedErrorId : PositionalParameterNotFound,Microsoft.PowerShell.Commands.UpdateTypeDataCommand

The data returned looks correct, I am looking for some servers that I know are different to confirm.

VersionInfo        : File:             C:\Windows\System32\NotePad.exe
                     InternalName:     Notepad
                     OriginalFilename: NOTEPAD.EXE.MUI
                     FileVersion:      6.1.7600.16385 (win7_rtm.090713-1255)
                     FileDescription:  Notepad
                     Product:          Microsoft® Windows® Operating System
                     ProductVersion:   6.1.7600.16385
                     Debug:            False
                     Patched:          False
                     PreRelease:       False
                     PrivateBuild:     False
                     SpecialBuild:     False
                     Language:         English (United States)

FileVersionUpdated : 6.1.7601.18917
ServerName         : ServerA

I will see what we have Don. “Cmd.exe tools”

Main goal is to confirm that the correct updated version of the DFSR.Exe exists on each DC…

The Update-TypeData approach is just one example of using the knowledge of the data structure.

You could also just compare the in-scope fields directly. For example if you only care about a specific field (in this example I’ll use build number) you could just do:
(Get-Item \server1\c$\windows\explorer.exe).VersionInfo.FileBuildPart -eq (Get-Item \server2\c$\windows\explorer.exe).VersionInfo.FileBuildPart

Also note that the Connect bug I created with the original blog post says it is fixed, but I’m not clear on where or how.

Check out these blog posts: Part 1 describes the cause of the problem and Part 2 shows examples.

Short version: it’s not a bug, just a confusing part of how version information is queried (see the Remarks section here)

Version 5 fixes the issue by providing FileVersionRaw and ProductVersionRaw script properties for FileInfo objects.

Thank You Rohn!!

I will read the remarks. We are stuck on V.4 at the moment but glad I am not alone in this.

Meanwhile I did get this working for the NotePad.Exe Will see if they can get the same results for dfsrs.exe.

$Computers = 'ServerA','ServerB','ServerC'

ForEach($Computer in $Computers)
{
Invoke-Command -ComputerName $Computer -ScriptBlock {(Update-TypeData -TypeName System.Io.FileInfo -MemberType ScriptProperty -MemberName FileVersionUpdated -Value {

    New-Object System.Version -ArgumentList @(

        $this.VersionInfo.FileMajorPart

        $this.VersionInfo.FileMinorPart

        $this.VersionInfo.FileBuildPart

        $this.VersionInfo.FilePrivatePart)})
Get-ChildItem "C:\Windows\System32\NotePad.exe" -Force | Select-Object -Property @{Name='FileVersion';Expression={$_.VersionInfo.FileVersion}},FileVersionUpdated,@{Name='ServerName';Expression={$env:COMPUTERNAME}}}}


Just need to tweak it a bit IF FileVersionUpdated does not exist…

FileVersion        : 6.3.9600.16384 (winblue_rtm.130821-1623)
FileVersionUpdated : 6.3.9600.17930
ServerName         : ServerA
PSComputerName     : ServerA
RunspaceId         : 48BR549--abc-deee-af72-fc8ed63f8888

FileVersion        : 6.3.9600.16384 (winblue_rtm.130821-1623)
FileVersionUpdated : 6.3.9600.17930
ServerName         : ServerB
PSComputerName     : ServerB
RunspaceId         : 48BR549--abc-deee-af73-fc8ed63f8889

A parameter cannot be found that matches parameter name 'TypeName'.
    + CategoryInfo          : InvalidArgument: (:) [Update-TypeData], ParameterBindingException
    + FullyQualifiedErrorId : NamedParameterNotFound,Microsoft.PowerShell.Commands.UpdateTypeDataCommand
    + PSComputerName        : ServerC

FileVersion        : 6.1.7600.16385 (win7_rtm.090713-1255)
FileVersionUpdated :
ServerName         : ServerC
PSComputerName     : ServerC
RunspaceId         : 48BR549--abc-deee-af74-fc8ed63f8890

Matthew,

Looking into this as well…

(Get-Item \server1\c$\windows\explorer.exe).VersionInfo.FileBuildPart -eq (Get-Item \server2\c$\windows\explorer.exe).VersionInfo.FileBuildPart

Using NotePad -

PS C:\WINDOWS\system32> (Get-Item \ServerA\c$\windows\System32\NotePad.exe).VersionInfo.FileBuildPart -eq (Get-I
tem \ServerB\c$\windows\System32\NotePad.exe).VersionInfo.FileBuildPart
True

Thank You for a Fantastic Post!