Deploy to multiple systems

[jc508]

Hi, I have 6 machines to setup with an identical set of metadata handlers and selected attributes. Is there a way to set it all up on one machine then export that configuration and apply/install it to the next machine in one step ?

Thanks JC

[Dijji]

Hi JC

Your best bet for reproducing configurations on multiple machines is the command line support. This is described here: https://github.com/Dijji/FileMeta/wiki/Managing-which-extensions-File-Meta-handles

You can create a batch file which will add the File Meta property handler for the desired extensions. If you need custom profiles, you can set them up on one machine, then distribute the definitions file that this creates with the batch file to set the same profiles up on other machines.

I hope that this helps you solve your problem.

Dijji

[jc508]

Dijji, Thanks I think that worked. Its a bit confusing considering 'profiles' and 'definitions' What I did was copy the SavedState.xml from the perfect / benchmark system to the new one. Then issued adds such as FileMetaAssoc.exe -a -p=.bmp .bmp for each profile named in the SavedState.xml file. Several extensions got my new basic profile. JC

[Dijji]

There can be many profiles, all of which are held in one definitions file. If you open that file up, you will see that it is just an XML representation of each of the profiles.

I wrote the command line tool assuming that you would copy the original definitions file to some arbitrary location on the target machine, and then reference it from the command line.

But if you are copying it to the same directory on target where it was found on the original, then I think it should work as desired without the -d parameter. You can check by comparing the .bmp profile on the target machine to that on the original using the File Association Manager on each.

Dijji

[beezerlm]

I am also looking to deploy FileMeta to multiple systems. Would it be possible to install FileMeta on all systems, then push out the profiles and definitions through Group Policy?

Edit: I forgot to mention, I would also like to apply or remove the FileMeta handler via group policy. My goal here is to be able to make all changes on the server and push those out to clients.

BTW - Thanks for making this awesome utility!

[Dijji]

I am no expert on Group Policy, but a quick read around seems to indicate that this could be done, although I've never done it and do not know of anybody who has.

Since File Meta is configured entirely through registry keys, it is a question of creating a custom Administrative Template that sets all of the required registry values. The registry settings used by File Meta are completely described in the documentation, and you can use the Association Manager on a local machine to discover the exact settings that are produced for your required set of extensions.

Also, as File Meta is installed using an msi, you could even create a group policy to install it.

If you give this a go, do post again and tell everybody about your experiences!

Dijji

[beezerlm]

Well I was able to install on a client via group policy. Here are some notes.

1. Added FileMeta msi to shared folder and GPO via Policies/Software Settings/Software Installations.
2. Had to add "Domain Computers" to GPO delegation tab.
3. Enabled "Allow inbound remote administration exception" via Policies/Administrative Templates/Network/Network Connections/Windows Firewall/Domain Profile (To check group policy results for users/computers).
4. Enabled "Always wait for the network at computer startup and logon" via Policies/Administrative Templates/System/Logon.
5. Enabled "Specify startup policy processing wait time" via Policies/Administrative Templates/System/Group Policy (set to 30 seconds).

I could not get it to install without steps 4&5. I rebooted the client many times and kept getting this message:

Software Installation did not complete policy processing because a system restart is required for the settings to be applied. Group Policy will attempt to apply the settings the next time the computer is restarted. | Software Installation did not complete policy processing because a system restart is required for the settings to be applied. Group Policy will attempt to apply the settings the next time the computer is restarted.

After adding steps 4&5 and a couple reboots File Meta was installed on the client.

Now I have to look at adding registry keys for profiles and handlers etc...

[beezerlm]

Ran into a slight roadblock, not every client machine has the same software installed on it. Some of the clients will need the handlers extended, while others need some handlers added (it will be a mix of both). This is on a case by case basis for many file formats. Is there any way to automatically handle this? My only alternative would be to look at every client individually and create a custom GPO for each machine (about 20 of them).

[Dijji]

Congratulations on your impressive progress so far!

So, onto the current issue. The actual difference between the registry footprint of the new and added handlers is twofold. In the added case, an extra private registry entry is created to record the original property handler so that it can be restored if the File Meta handler is removed, and so that properties read by the original handler will still be available. Also, in the added case, a custom profile is always created that merges the File Meta profile selected with the original catalogue of properties available in Explorer, and again, a private entry is created to hold the original property set. So, if you take the registry settings from a machine where the handler was added, but omit the private, backup settings, you will have settings that will work everywhere. The loss will be that you will not remember what the original property handler was.

This will result in a behavioural difference: in the added case, File Meta will use the original property handler read-only to retrieve any properties specific to the original handler. Without the original handler being recorded in the registry, the one size fits all strategy will lose property values set by the original handler.

This may be tolerable, in your case. Another approach would be to always set the private registry entry for the backup handler. Of course, this will make most sense if the original handler is consistent across your machines. There should be no problems if the original handler is not installed everywhere, it simply won't be instantiated when it's missing. If the original handler is variable, and access to the relevant properties is important, then some sort of partition at the policy level would be required to avoid writing a custom installer.

A rather long answer, but I hope it helps.

Dijji

[beezerlm]

I am currently trying to push out software installation via GPO to standardize the machines here. While pushing out ApacheOpenOffice msi, my FileMeta test machine was updated to the newer version. I believe it just uninstalled/reinstalled rather than updated. The format for these files is no longer bold in Association Manager and FileMeta is no longer listed as a handler. The profiles are still in the SavedState.xml. Here are some screenshots of the registry now:

I have backups of these registry settings from before this happened. Can I just restore the two PropertyHandlers keys to fix this, or does it get more complicated than that?

[Dijji]

Using the Association Manager to add the handler again using the custom profile will probably be the best way forward. This will set up the property handler again, and also recreate the Explorer property lists. There is some risk due to the odd current state of the registry, but I think this should work. Restoring the property handlers will get that side of things working, but may not get the Explorer properties back to the right state, unless you can restore those registry settings too.

Dijji

[beezerlm]

Which explorer properties are you referring to? The list of available properties? I have a GPO pushing default columns to all machines for this registry and it's subkeys:

Computer\HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FolderTypes\{5c4f28b5-f869-4e84-8e60-f11db97c5cc7}

This forces all machines to have the same columns (after deleting shell bags) for the "Generic" folder type.

[Dijji]

My bad. I meant the FullDetails, PreviewDetails and InfoTip values on the subkey for the extension under SystemFileAssociations.

[beezerlm]

Oh yes I have those too. I will give it a go with the registry settings and let you know what happens.

[beezerlm]

Well I restored the registry for the .ods and .odt extensions and everything seemed back to normal except the FullDetails. Right clicking the file and going to properties -> detail tab showed what looked to be the default list of properties. All SystemFileAssociations & PropertyHandler registry entries look correct to me so I am not sure why they don't show up?

I opened the Association Manager and removed the handler and then reapplied it for .ods and FullDetails is working as expected again. I must be missing a registry entry somewhere?

I left the .odt in the broken state so I could compare registry entries between the two. So far, I can't find any difference between the two.

[Dijji]

No, I think you've covered all the registry keys. I'm down to the usual restarting Explorer (including the desktop) requirement. It might be interesting to go back to the broken settings and see if the problem recurs. But if they're identical…

[beezerlm]

Moving on to next step for deployment. If I want to push my settings for the .txt extension from my test machine to another machine which already has FileMeta installed, would I just have to push registry settings for SystemFileAssociations and both property handlers? For example I would push these keys and all sub keys:

HKEY_CLASSES_ROOT\SystemFileAssociations\.txt
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\PropertySystem\PropertyHandlers\.txt
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\PropertySystem\PropertyHandlers\.txt

Is it necessary to push anything else? Is the SavedState.xml file needed if the Association Manager/command line tool will not be used to make changes on the machine?

[Dijji]

No, you have listed all the keys that are needed. Also, you do not need deploy anything else, including the SavedState file, on the clients if you are not running the command line tool.

[beezerlm]

I pushed those keys to another machine for the .txt format and everything worked well.

I do have another hurdle to get over ( sorry... i've been keeping you busy ). I have found some programs don't keep the metadata intact when making modifications to files. For example, if I make a markup on a pdf file and save it, the metadata is gone. I have found the same thing with all the SolidWorks formats. Is there anyway to retain this metadata without having to back it up and reload it every time you save?

[Dijji]

Great news on the registry key deployment!

Unfortunately I do not have any solution for your other problem. This is a characteristic of programs that use an update strategy that goes: write new file, delete old file, rename new file to old file name. This has the benefit of protecting the original file should a problem occur while writing the new one, but destroys any meta data to the old file when it is deleted.

Annoying, but I know of no way round it.

Dijji

[beezerlm]

Well I have been trying to find a solution to the PDF issue. I am working on moving us paperless and marking up pdf blueprints while maintaining the metadata is a big part of that. I tried using Foxit pdf viewer but that did the same thing as Adobe. I also tried Nitro and it doesn't remove the metadata on save, but it costs $159 per user. I will continue to hunt for a free/cheaper solution before I push FileMeta into production.

[beezerlm]

There must be something unique about the open office registry entries. I pushed the registry entries for the .odt and .ods format to the second test machine. The correct metadata shows up in the preview pane, but full details shows the system default, as if there is no property handler. It's the same issue I had on the first test machine (post from 7 days ago).

It appears all works well when using the association manager, but when pushing registry keys the full details won't take for some reason.

[Dijji]

If you would care to post the registry values for the preview and full details panes that you are using, I will try and reproduce your problems here. Otherwise, I'm rather struggling to think how I can help, unless you have any other ideas.

Dijji

[beezerlm]

This is for the .odt extension.

[HKEY_CLASSES_ROOT\SystemFileAssociations\.odt]
"FullDetails"="prop:System.PropGroup.Description;System.Title;System.Author;System.Subject;System.Keywords;System.Comment;System.Document.RevisionNumber;System.PropGroup.FileSystem;System.ItemNameDisplay;System.ItemType;System.ItemFolderPathDisplay;System.Size;System.DateCreated;System.DateModified;System.FileAttributes;System.ComputerName;System.FileName;System.Keywords;System.ItemTypeText;System.FileOwner;System.FileVersion;System.Comment"
"InfoTip"="prop:System.FileName;System.FileAttributes;System.Keywords;System.FileVersion;System.ItemTypeText;System.FileOwner;System.DateCreated;System.DateModified;System.Size;System.Document.RevisionNumber;System.Comment"
"PreviewDetails"="prop:System.FileName;System.FileAttributes;System.Keywords;System.FileVersion;System.ItemTypeText;System.FileOwner;System.DateCreated;System.DateModified;System.Size;System.Document.RevisionNumber;System.Comment"
"FileMetaCustomProfile"=".odt"

[HKEY_CLASSES_ROOT\SystemFileAssociations\.odt\ShellEx]

[HKEY_CLASSES_ROOT\SystemFileAssociations\.odt\ShellEx\ContextMenuHandlers]

[HKEY_CLASSES_ROOT\SystemFileAssociations\.odt\ShellEx\ContextMenuHandlers\FileMetadata]
@="{28D14D00-2D80-4956-9657-9D50C8BB47A5}"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\PropertySystem\PropertyHandlers\.odt]
@="{D06391EE-2FEB-419B-9667-AD160D0849F3}"
"Chained"="{AE424E85-F6DF-4910-A6A9-438797986431}"

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\PropertySystem\PropertyHandlers\.odt]
@="{60211757-EF87-465e-B6C1-B37CF98295F9}"
"Chained"="{AE424E85-F6DF-4910-A6A9-438797986431}"

I noticed when I right click a file and select "properties" Open Office adds another tab called "Document Statistics". This appears to still be functioning at a glance.

[Dijji]

I tried your key values on a random extension, and they worked fine, even though the same properties (e.g. Comments) appear in more than one property group in Full Details. I thought this would be a problem, but they just show up in both groups!

So then I installed OpenOffice to have a look at the specific keys that it sets up. I observed that it does not set up anything under SystemFileAssociations, but it does have entries under HKEY_CLASSES_ROOT.odt and .ods. The default value of the former, for instance, points to HKEY_CLASSES_ROOT\opendocument.WriterDocument.1, which, lo and behold, does not have a PreviewDetails value, but does have a FullDetails value. In looks like that this value is winning over the competing offering in SystemFileAssociations, but that the PreviewDetails value, without competition, is working as intended.

What happens if you remove the FullDetails value from HKEY_CLASSES_ROOT\opendocument.WriterDocument.1?

Dijji

[beezerlm]

I removed the FullDetails as you mentioned and it worked for the .odt format. Is removing this value the best way to proceed with group policy implementation?

[Dijji]

I think so. This entry comes from the old way of specifying FullDetails et cetera that is obviously still used by Open Office. File Meta used the same pattern up until version 1.3, and it is still described in the File Meta documentation. I did not know, however, that it would take precedence: these rules are not described everywhere.

Dijji