Wrong version of Word detected

[Imaginos]

Hi Markus

On a TSE server, I have an issue with only one user, here's the log :
`**********************
Début de la transcription Windows Powershell
Heure de début : 20230605113727
Nom d'utilisateur : DOMAINE\d.xxxx
Utilisateur runAs : DOMAINE\d.xxxx
Ordinateur : TSE2016AA (Microsoft Windows NT 10.0.14393.0)
Application hôte : powershell.exe -WindowStyle Hidden -ExecutionPolicy ByPass -File C:\Logiciels\Scripts\Signatures.ps1
ID de processus : 19032
PSVersion: 5.1.14393.5127
PSEdition: Desktop
PSCompatibleVersions: 1.0, 2.0, 3.0, 4.0, 5.0, 5.1.14393.5127
BuildVersion: 10.0.14393.5127
CLRVersion: 4.0.30319.42000
WSManStackVersion: 3.0
PSRemotingProtocolVersion: 2.3
SerializationVersion: 1.1.0.1

---

Transcription démarrée, le fichier de sortie est C:\Users\d.xxxx\Signatures.log
OK : Settings disponible
ATTENTION : Lancement manuel
OK : Script disponible
OK : Fichier ini disponible
OK : Fichier de remplacement disponible
OK : Dosier des template disponible
OK : Dossier OOF disponible
OK : Fichier ini des OOF disponible
OK : Modèle de signature disponible
ATTENTION : L'image sera integrée
OK : Word et Outlook sont présents
OK : Donnée OK pour la valeur HKCU:\SOFTWARE\Microsoft\Office\16.0\Outlook\Options\Mail\Send Pictures With Document
ATTENTION : Mise à jour de la signature nécessaire

Start script @2023-06-05T11:37:28+02:00@

Script notes @2023-06-05T11:37:28+02:00@
Script : Set-OutlookSignatures
Version: v3.5.1
Web : https://github.com/GruberMarkus/Set-OutlookSignatures
License: MIT license (see '.\docs\LICENSE.txt' for details and copyright)

Check parameters and script environment @2023-06-05T11:37:28+02:00@
PowerShell: '5.1.14393.5127', 'Desktop'
PowerShell bitness: 64-bit process on a 64-bit operating system
PowerShell parameters: ' & $Script.f_OutlookSignatures -EmbedImagesInHTML $EmbedImagesInHTML -SetCurrentUserOOFMessage $false -SignatureTemplatePath $Script.d_templates -OOFTemplatePath $Script.d_OOF -SignatureIniPath $Script.f_Template_Ini -OOFIniPath $Script.f_OOF_Ini -ReplacementVariableConfigFile $Script.f_replacement -GraphConfigFile $Script.f_GraphConfigFile
'
Script path: 'C:\Logiciels\Set-OutlookSignatures\Set-OutlookSignatures.ps1'
TrustsToCheckForGroups: '*'
IncludeMailboxForestDomainLocalGroups: 'False'
SignatureTemplatePath: '\mercure\partage\Applicatifs\MAILS\Signatures'

SignatureIniPath: '\domaine.local\NETLOGON\Set-OutlookSignatures\INI\signatures.ini'

SetCurrentUserOutlookWebSignature: 'True'
SetCurrentUserOOFMessage: 'False'
UseHtmTemplates: 'False'
GraphOnly: 'False'
GraphConfigFile: 'C:\Logiciels\Set-OutlookSignatures\config\default graph config.ps1'

GraphCredentialFile: ''

ReplacementVariableConfigFile: '\domaine.local\NETLOGON\Set-OutlookSignatures\config\replacement variables - LaNormandise.ps1'

EmbedImagesInHtml: 'True'
CreateRtfSignatures: 'True'
CreateTxtSignatures: 'True'
DeleteUserCreatedSignatures: 'False'
DeleteScriptCreatedSignaturesWithoutTemplate: 'True'
SignaturesForAutomappedAndAdditionalMailboxes: 'True'
AdditionalSignaturePath: 'C:\Users\d.xxx\Documents\Outlook Signatures'

SimulateUser: ''
SimulateMailboxes: ''

Get basic Outlook and Word information @2023-06-05T11:37:28+02:00@
Outlook
Registry version: 16.0
File version: 16.0.5257.1000
Bitness: x86
Default profile: Outlook
Is C2R Beta: False
DisableRoamingSignaturesTemporaryToggle: 0
Word
Word version 12.0.0.0 is older than Word 2010 and not supported. Please inform your administrator. Exit.

Clean-up @2023-06-05T11:37:29+02:00@

End script @2023-06-05T11:37:29+02:00@

---

Fin de la transcription Windows PowerShell
Heure de fin : 20230605113729

---

`

Office 2016 Standard is installed

[GruberMarkus]

Hi @Imaginos,

Set-OutlookSignatures queries the registry key HKEY_CLASSES_ROOT\Word.Application\CurVer to find out which version of Word is installed according to registry entries.

Please check this key for existence and content. If it does not exist or not have the value "Word.Application.16", please try to repair your Office 2016 installation. Do not just create the registry key or copy it from another system.

There are other keys Set-OutlookSignatures queries to find winword.exe in the file system and to log its file version. These keys should also exist:

• HKEY_CLASSES_ROOT\Word.Application\CLSID
• HKEY_CLASSES_ROOT\CLSID<value of HKEY_CLASSES_ROOT\Word.Application\CLSID>\LocalServer32

[Imaginos]

In HKEY_CLASSES_ROOT\Word.Application\CurVer , I find Word.Application.16.
But in HKEY_CLASSES_ROOT\CLSID{000209FF-0000-0000-C000-000000000046}\ there is no "LocalServer32" key but only "InprocServer32".

[GruberMarkus]

Please run the following PowerShell Code and post the output:

Get-ItemProperty 'Registry::HKEY_CLASSES_ROOT\Word.Application\CurVer'

$WordRegistryVersion = [System.Version]::Parse(((((((Get-ItemProperty 'Registry::HKEY_CLASSES_ROOT\Word.Application\CurVer' -ErrorAction SilentlyContinue).'(default)' -ireplace 'Word.Application.', '') + '.0.0.0.0')) -replace '^\.', '' -split '\.')[0..3] -join '.'))

Write-Host "WordRegistryVersion: $WordRegistryVersion"


try {
    $WordFilePath = Get-ChildItem ((([Microsoft.Win32.RegistryKey]::OpenBaseKey([Microsoft.Win32.RegistryHive]::ClassesRoot, [Microsoft.Win32.RegistryView]::Registry32)).OpenSubKey("CLSID\$((Get-ItemProperty 'Registry::HKEY_CLASSES_ROOT\Word.Application\CLSID' -ErrorAction Stop).'(default)')\LocalServer32")).GetValue('') -split ' \/')[0] -ErrorAction Stop
} catch {
    try {
        $WordFilePath = Get-ChildItem ((([Microsoft.Win32.RegistryKey]::OpenBaseKey([Microsoft.Win32.RegistryHive]::ClassesRoot, [Microsoft.Win32.RegistryView]::Registry64)).OpenSubKey("CLSID\$((Get-ItemProperty 'Registry::HKEY_CLASSES_ROOT\Word.Application\CLSID' -ErrorAction Stop).'(default)')\LocalServer32")).GetValue('') -split ' \/')[0] -ErrorAction Stop
    } catch {
        $WordFilePath = $null
    }
}

write-host "WordFilePath: $WordFilePath"

It could be a problem with an older Set-OutlookSignatures version. You use v3.5.1, while there is v3.6.1 available.

[Imaginos]

Here's the result :
`(default) : Word.Application.16
PSPath : Microsoft.PowerShell.Core\Registry::HKEY_CLASSES_ROOT\Word.Application\CurVer
PSParentPath : Microsoft.PowerShell.Core\Registry::HKEY_CLASSES_ROOT\Word.Application
PSChildName : CurVer
PSProvider : Microsoft.PowerShell.Core\Registry

WordRegistryVersion: 16.0.0.0
WordFilePath: C:\PROGRA2\MICROS1\Office16\WINWORD.EXE`

I know about v 3.6.1 but it creates oversized pictures and I didn't had the time to raise a ticket about it.
So, I can't use this version (idem with 3.6.0)

[GruberMarkus]

I don't see a problem with the output of the PowerShell Code above. It's basically the same that raises the error you documented in your first post.

v3.6.1 does not produce oversized images itself, it is Word doing that. Please give v3.6.1 a try:

• First, only let it run until the Word version detection is done. Does it work in v3.6.1?
• Second, read the new FAQ "Images in signatures have a different size than in templates" you can find in '.\docs\README' of v3.6.1.

[Imaginos]

It's a bit hard to test because I must use a specific user account.
On this server all other accounts work great.
The issue appears with only one (over 30 used on this machine)

[Imaginos]

Concerning the image size, I wonder why this wasn't a problem until v 3.6.
I won't upgrade because of this.
It will be much annoying to resize precisely the pictures in a software before integrating them in the docx as Word can do the resize and moreover because it work with the previous versions.
It's a sad regression.

[GruberMarkus]

Concerning the image size, I wonder why this wasn't a problem until v 3.6. I won't upgrade because of this. It will be much annoying to resize precisely the pictures in a software before integrating them in the docx as Word can do the resize and moreover because it work with the previous versions. It's a sad regression.

It is not a regression. The timeline is as follows:

1. v3.6.0 introduced the new parameter DocxHighResImageConversion
2. The new parameter works fine for several months (despite a bug in combination with 'EmbedImagesInHtml false')
3. Microsoft releases new Office builds, in which the Word HTML renderer, which is used by Outlook, ignores the width and height attributes of embedded images.
4. v3.6.1 fixes the bug mentioned in 2, and adds extensive documentation about 3. The new FAQ 'Images in signatures have a different size than in templates' shows the root cause of the problem (a bug in Word), and which workarounds you can realize with Set-OutlookSignatures v3.6.1. If you want to save time on details, just read through the table at the end of that FAQ.

[GruberMarkus]

It's a bit hard to test because I must use a specific user account. On this server all other accounts work great. The issue appears with only one (over 30 used on this machine)

Oh, that's important and new information.

That makes the error user specific, and there will be no way around testing with the problematic user. Maybe its a registry permission problem?

[Imaginos]

For the image : I saw a first information in the FAQ and I didn't go to the specific section. My bad, i'm gonna check this.

For the specific user :
I mentionned it in the first post :)
I also bet it's a registry issue...

[GruberMarkus]

Then we both overread something and are even. :)

Regarding the registry issue: Have the user run the code I send you before. I guess you will receive an error message, which hopefully contains details.

• There is no specific error in Set-OutlookSignatures, because the registry key is read with "-erroraction silentlycontinue", resulting in version 0.0.0.0, which in turn is smaller than 14.0.0.0 and thus leading to the "Word 2010 or older" error from post 1.
• It could be a permission problem on HKCR\Word.Application\CurVer. If it's obvious, you can see it in a registry editor.
• I don't think it got something to do with registry virtualization, because - as far as I know - HKCR is never virtualized
• Please also check the following: HKCR ist combined view of HKLM\Software\Classes and HKCU\Software\Classes - with HCKU having priority over HKLM. So please check if there is HKCU\Software\Classes\Word.Application\CurVer and which default value is defined there.

[Imaginos]

For the user, I may have an explaination.
The user has installed a fu*** app called WPS Office, you may have heard about it.
It sets in the appdata roaming subfolder and creates a mess in Office install.
We will first try to act on this (wich means removing the profile folder and key).

I'll let you know :)

[GruberMarkus]

Hi @Imaginos,

could you solve the problem?

[Imaginos]

Hi Markus
I asked the support to reset the user profile on the TSE.
It hasn't been done yet, so I can't confirm.
Dont' worry, as soon as it's done, I'll report here :)

[GruberMarkus]

Hi @Imaginos,

could you check HKCU\Software\Classes\Word.Application\CurVer?

[GruberMarkus]

Closing issue due to inactivity.

@Imaginos can re-open this issue anytime when new information is available.