Dave-H

No, me neither. Some background on DLL loading priorities here. Doesn't seem to solve the problem though!

I'm getting a different error message "An error has occurred: 0x800B0100 No signature was present in the subject".

OK, yes I realise you're using a clean install! What I'd like to know is whether anyone else who has a fully POSReady updates patched system has this working. If nobody can show this, I think we have to assume that one or more of the POSReady updates is the problem. I don't think I'm going to be going back to a clean install just to fix this, but it would be good to know one way or the other!

You're trying to use the later version, which only runs on Windows 10 apparently! See earlier posts.

I'm only working from my very faulty memory here, but is that dll listed in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs? IIRC, if it is there programs will always use the version in system32. If it's there, remove it and try again.

Tried that, and both WUMT and the script just complain that the service isn't running and cannot be started. Again, can anyone confirm that this works on a system with all the POSReady updates applied? We've found (see other current threads) that a couple of those updates stopped Office 2010 encryption working properly, which I don't think anyone was aware of before, so is it possible that a POSReady update or updates has also hosed this?

Yes, works fine with the older file just in the Office program folder, no need to change the system file!

That file doesn't exist by default in the Office program folder, only in \system 32. Putting any version in there should not be a problem.

Wow, great news! My version of dssenh.dll in \system32 is 5.1.2600.7345. The version in KB3081320 is 5.1.2600.6924. I guess a subsequent update changed the system version, probably causing the Office encryption problem, but if the older version of the file is in the Office program folder it still uses that. Great result!

Just to add, I did stop the Automatic Updates service, disabled the DataStore folder by renaming it (I don't want to lose my update history) and when I ran the script it started the service again and recreated the folder, which is expected I assume. Still the same end result though.

Guess what, exactly the same result with the vbs script as with WUMT! I would really love to know what's causing this!

@Condor.07 Just a quick thought. Do you have the POSReady updates installed on your system?

Good luck with that, even @heinogandahad to concede defeat there!

I have exactly those files, and I've set WUMT up as in your image, but still no joy. I'm still seeing on every boot three error entries a second or so apart in the Windows Application Event Log. This started happening when I tried to run MBSA, which reported that it had failed to download the update database. I now don't seem to be able to stop the error messages. All the research on it seems to say you need to trash the DataStore folder in the Windows\SoftwareDistribution folder, but in my case this makes no difference, I'm still getting the error messages. I can't help but think that these two issues are related! Any suggestions gratefully received!

Great result, only two items, it could have been a lot worse! Both of those updates relate to the adding of TLS 1.1 and 1.2 support to Windows XP. I guess if you use anything which needs them uninstalling the updates will break that. Although I don't use IE8 for anything now of course, Microsoft Update being the last exception, and that has now it seems permanently broken, I do use the IE8 engine as the message viewer in my Eudora e-mail program, so things could break there if I remove those updates. As personally I never deal with encrypted Office documents, I will almost certainly leave things as they are.

Great work!

Ah, thank you! So it looks as if the version of WUML I've already got is the last version which will work on XP anyway. If anyone has it working offline with wsusscn2.cab please talk me through exactly what settings you're using, as I'm still not getting anywhere with it!

Some clues here maybe? This was written in 2012, and unfortunately the Technet document it references seems to have been updated for Office 2016, so I don't know how relevant it now is to Office 2010. The item does say as one point "there are Office 2010 settings to change how encryption is performed". Well if there are, I can't find them!

I've done some more experimenting, and it seems as if the encryption on new Word documents does work on my Office 2010 on XP, but only if you save them as legacy .doc format files, not if you save them as the newer XML .docx format files. It seems as if encrypting the newer .docx version of Word documents needs encryption formats which are probably not available on XP. Of course that is no help whatsoever if you're trying to open existing encrypted documents which have already been saved in the newer format! I think this is an operating system problem, the encryption types are not something that comes with Office itself, they are part of the OS.

So do you think that the version of WUMT I have needs to be changed? As I said, I've had it for years and it's always worked fine when I've used it, but this is the first time I've tried using it in offline mode. I wasn't aware of a later version being available. I'm pretty sure that the version of wsusscn2.cab that I have is correct. The date of the file is the date it was downloaded, but the signing dates and hashes seem to be correct. What's "MDL" BTW? I can't find anything relevant in searches.

Well I've never used document encryption, and I've never had to deal with an encrypted document, but I can certainly confirm that it doesn't seem to be working! I've tried encrypting a new document, and it will not do it. Whether this has always been the case on XP I cannot say, as I've never tried it before, but it certainly doesn't work now. Just to add, FWIW, the encryption works absolutely fine with the 64 bit version of Office 2010 on Windows 10!

So has anyone got this cabinet to work in WUMT, because it won't for me? Perhaps I'm just doing something wrong.

Sorry, went to bed! Yes, I guess that will always be the reported version of the actual Office Suite on XP now because of having to use the old MSO.DLL, as you say. I'm happy that my installation is as up to date as it can be, so if yours is reporting the same versions, I think you can be confident that yours is too. There may well be a few more updates to the individual components before EOS in October. I take it your DLL substitution worked OK on the final installation? I hope you can automate it somehow. Cheers, Dave.

If you look at the Help section of Word, say, mine says 14.0.7214.5000. However, if I look at "Additional Version and Copyright Information", it's shown as 14.0.7254.5000.

Well yes of course, but I didn't see that they had contributed to this thread recently! Anyway, I hope the DLL replacement now works!