Author Posts

November 17, 2015 at 7:38 am

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..?

November 17, 2015 at 9:17 am

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?

November 17, 2015 at 9:22 am

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

November 17, 2015 at 9:24 am

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...

November 17, 2015 at 9:49 am

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.

November 17, 2015 at 10:06 am

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.

November 17, 2015 at 10:57 am

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

November 17, 2015 at 11:04 am

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!