Selective sync?

[dbaldacchino]

We will have situations where we want to control certain tools, such as when testing a tool in one office only before releasing firm-wide. An example is Mission Control (MC) where we want to test in NY only for a while. If we use Zombie in its current format, we can control who gets the released version of MC by limiting installs of Zombie, but that won't be the case in the future when most machines have it installed. Here's one thought on how we can control that:

1. Add an optional setting to the settings file so if a package is to be released to a controlled group, the tool will look for the existence of a text file at the specified path. This file can be manually placed or distributed via group policy to a set number of machines.

2. If Zombie finds this file, it proceeds (looks up if the application that uses the files/addins is installed and if so, syncs the content).

3. If not, it exits.

Other ways of managing this would be to include a list of machines in a database that you manage and the machine name is checked against the list and if found, syncs content; abort otherwise.

[ksobon]

@dbaldacchino don't we have that ability already? Think about it this way.

• Zombie is installed on everyone's machine.
• It gets its settings using the Registry path to a file on GitHub.
• We can simply point the Registry path for NY users (test group) to a different Settings path, that has extra tools for testing.

So basically we can do custom distribution just by tapping into select users registry and overriding the path. I guess that installation BAT file you use in a Software Center, can be copied, so that we have two (2).

• one would install the full release and point at settings file for that.
• one can be made available to select users (NY), and point at a different settings file that has more stuff in it.

Would that work?

[dbaldacchino]

That would work too. I could talk to Jerry about setting up a GP for specific machines (let's say all NY machines as an example of a test group) where a script runs to change the registry key. I could then maintain it with no IT intervention as needed. Alternatively we just manage it completely in GP and get with IT every time we need to change it.

[ksobon]

I vote for no IT involvement. GP (group policy) sounds good to me as well.

Ps. I will keep this issue open for now. I am 99% sure that we can do it like this, but I would want to test just to make sure. So I will close it when I have tested this approach and confirmed that it's good to go.

[dbaldacchino]

GP implies IT involvement :D But if we predefine settings for various computers as discussed over the phone (ex: NY computers to get a different settings file so we can publ;ish different addins to test on those machines, then later match both settings files when they're ready to be published to the masses). This avoids messing with GP altogether to change registry settings and achieve the same goal, however that will remain as an option if needed.

[ksobon]

GP implies IT involvement :D

Fair point.

OK, I made a copy of the current settings. Let's use that for NY users only. So basically we need two (2) BAT install scripts that we can hand to IT and tell them this is for NY, and this is for everyone else. That way we can have NY point at a different settings path: https://github.com/HOKGroup/Zombie_Settings/blob/master/ZombieSettings_beta.json

[dbaldacchino]

No need for separate scripts; I’ll update the installer to use one or the other based on the machine prefix.