Problem:
I work for different customers in for example Health Care and Educational environments in which multiple administrators do create and change content (Bundles, Policies) in ZCM. This content does target different workgroups of people in the organisations, for which mostly are one or several 'testers' of these opposed changes. Once marked 'Test', a user of device does get all the Sandboxed Bundles and Policies to it. We cannot specify who get's specific sandboxed content. In real live we want someone to try a sandboxes Bundle in production, but not a sandboxed policy or for that another bundle which may have other testers assigned to it.
Solution:
I propose we implement the ability to create multiple Sandboxes in ZCM. These sandboxes can be assigned to a user or device. This will allow the administrator to publish sandboxed content only to all or a specific sandbox. The Sandboxes work like a filter, if nothing is specified on a user or device, one get's all that is published as a sandbox.
Implementation suggestion:
-In ZCM> Configuration> Content> Sandbox, have the ability to set up sandboxes like 'Financial', ' Student', 'MyTestGroup', 'Site A'', 'Policy test X', ... anything...
-When a user, device is marked 'Test', also setup the filters by selecting one or multiple Sandboxes that are defined.
-On (global) Folders, Bundels, Policies: define default Sandbox(es) to publish in. This allows the admin to define on a Bundle or Policy level a default sandbox to publish in, while on the Folder or System-level the default sandbox my still be different.
-Default on a global level we could set a default Sandbox as 'None' or 'All', forcing the admin to think about how to setup Sandboxing. This allows in a small environment to select at a global level 'All' , so users and devices will receive all Sandboxed content. This would only be the case when on a user or device level no sandboxes are specified. This will make ZCM work as it does today.
Benefit:
This allows for multiple test groups of users and devices which do not do damage to each other.
This allows a test user in the organisation to receive only Bundle Sandboxes for like ' Financial', while another user/device may receive both 'Student' and 'Site A' sandboxed content.
This allows a test device to receive 'Financial' and 'Policy Test X', or if no specific sandbox is specified all sandboxed content (Globally defined as 'Any').
by: Sebastiaan V. | over a year ago | Application Mgmt
Comments
Add on:
Recently I've been setting up Patch Management at different sites and with this products having multiple Sandboxes would make life much easier.
Those customers I work with have like a mix of platforms and Office versions;
- Windows 7 x86, Office 2007 (x86)
- Windows 7 x64, Office 2007 (x86)
- Windows 7 x86, Office 2010 (x86)
- Windows 7 x86, Office 2013 (x86)
- Windows 7 x64, Office 2013 (x86 or x64)
- Windows 8.1 x64, Office 2013 (x64)
For any of those group of machines obviously at lease one machine should be in Test (Sandbox) mode. I prefer not to have more than one or two machines that do the patch-testing-before-auto-publishing. Now I like to setup a VM (setup with a high refresh and patch frequency) that is a Test machine for those patches and then associate a patch policy with that; so patches get tested before published to the patch group. Consequence of this is that as in the above example for 'Windows 7 x86 Critical Patches' automatically three machines are Test machine for those patches. This is true cause there are also patch policies as
- Office 2007 x86 Critical Patches
- Office 2010 x86 Critical Patches
- Office 2013 x86 Critical Patches
- Office 2013 x64 Critical Patches
Case the one running Office 2010 is just a small group of laptops not frequently entering the Office that results in a short windows to get those patches tested on such a device and deployed at an acceptable frequently to that group of machines.
My patch-test VM1 (w7x86, Office 2007) has assigned the patch policies
- Windows 7 x86 Critical Patches
- Office 2007 x86 Critical Patches
Now if we were able to assign both to this device and those (patch) bundles a Sandbox called like 'Sandbox Window 7 x86 and Office 2007 x86' the patches for patch policy 'Windows 7 x86 Critical Patches' would be tested only to this device before being auto published to the patch-group. That is, the devices running Office 2010 and Office 2013 do also need these Windows patches, but I do not want the be part of this Sandbox.
I would the create two more sandboxes; first 'Sandbox Window 7 x86 and Office 2010 x86' which has the patch policy 'Office 2010 x86 Critical Patches' assigned, and a Sandbox 'Sandbox Window 7 x86 and Office 2013 x86' which has the policy 'Office 2013 x86 Critical Patches'. The three Sandboxes all now have a single device testing the different office version patches and just one of them is used to also used to test the Windows 7 patches. Anyway will the other two Sanboxed devices receive the Windows 7 patches as soon as the policy has been published.
Having a Sanboxed VM for testing patches is convenient for troubleshooting patches and makes sure patches get published soon after being available in the system. It also prevents us from being dependent on (test) system in the organization if we do not want that.
Having Multiple Sandboxes allows for flexibility in testing and prevents us from the need to create a bunch of 'Test' devices which need to test any combination of patches before being published to a reflecting patchgroup of devices. Combinations get harder to test as there is also a need to have like multiple adobe versions in the organization and maybe even other products; we can not have a 'test' VM for any combination as the test group for like the Windows patches will grow with that.
We also need more sandboxes and want to use it for testing different groups like application bundles, patch policies, security policies before rolling out the different types of devices used within our company.