Wrong version of Word detected about set-outlooksignatures HOT 16 CLOSED

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

from set-outlooksignatures.

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

from set-outlooksignatures.

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.

from set-outlooksignatures.

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)

from set-outlooksignatures.

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.

from set-outlooksignatures.

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)

from set-outlooksignatures.

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.

from set-outlooksignatures.

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.

from set-outlooksignatures.

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?

from set-outlooksignatures.

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

from set-outlooksignatures.

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.

from set-outlooksignatures.

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 :)

from set-outlooksignatures.

Hi @Imaginos,

could you solve the problem?

from set-outlooksignatures.

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 :)

from set-outlooksignatures.

Hi @Imaginos,

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

from set-outlooksignatures.

Closing issue due to inactivity.

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

from set-outlooksignatures.