Thanks to everyone who joined our webinar with Juriba. Here is part 2 of the questions and answers from our two expert hosts.
Question: Do you have a reservation system — e.g. reserving testing equipment, tracking compliance of testing, etc.
Answer: Juriba Dashworks can certainly track these items, but it is not in itself a packaging workflow or application UAT testing system. That said, we often integrate with both third party and internal tools to help drive the process. As an example, at one large customer, users receive an email from Dashworks when their application readiness is green. This email contains an RDP link that triggers a VM build with the specific user applications so that they can test their target state machine ahead of the rollout. From there, a tool from Access PLC is loaded for signoff, and this signoff is returned to Dashworks so that the migration process can continue.
We certainly have plans in the near future to look into this capability so that customers can both manage the scheduling and logistics of migration alongside the whole application lifecycle management piece.
Question: Is the expectation that a semi-annual channel release will be that substantial that all applications will need to be tested against them each time?
Answer: This is a great question and one that unfortunately we have no definitive statistics on yet to be able to answer authoritatively. That said, we do know that the code changes for the initial releases of Windows 10 were significant, but the volume of changes is dropping with each new release, so the expectation is that the impact should be lower. Microsoft is continuing to say that each release should have a minor impact on application compatibility.
However, the challenge is not necessarily in the volume of changes, but in the ‘what’ is changing. For example, let’s say that .Net Framework 4.5.2 becomes a non-supported component. This would have a potentially huge impact on a large number of in-house applications and vendor applications. The as-a-service model will drive us to the latest standards, and we must expect some application remediation work as a result.
The critical element here is to understand what impact each release is having on your specific environment. If you are in a well-managed estate, this would mean investigating one of the application package assessment tools. In a more open estate, this would mean using a tool like Windows Readiness to assess the vendor apps and supplement this with some testing of your in-house apps.
Question: Does Juriba Dashworks aid in “projecting” velocity of deployment (How fast can we go?), completion of W10 deployments, and comparing different time periods of deployments against others?
Answer: Velocity of deployment is an interesting subject that has multiple dimensions. How fast you can go is typically dictated by a number of factors (not just application readiness):
- Application Readiness
- Infrastructure Readiness
- Business Readiness
- Hardware Compatibility / Lifecycle (i.e. do we need to tie the update to a refresh)
- User Readiness
- Network Readiness
- Deployment Capacity
- Service Desk / Deskside Support Capacity
On a purely mathematical basis, you tend to find that the application readiness to the most part, dictates the velocity of deployment. For example, at Juriba we use some PowerBI reporting to assess the ‘perfect’ application readiness plan to drive velocity. However, this plan may be at odds with the reality of the organization’s readiness. For example, there is no point leaving a hugely complex application at the back of the queue if it means risking those devices being out of support before the remediation can occur.
Therefore, the key here is to define a pragmatic deployment ring plan that gives you the right application coverage within the other readiness constraints. The Juriba tooling can help with this forecasting of velocity by showing the workload associated with each change in deployment ring membership, and by planning the best application route. You can also model some scenarios – e.g. what if I turn all of these applications green … how many devices can I deploy.
Of course, there is also some great technology from 1E in the form of Nomad that can help distribute the updates much faster, bring more robustness into the update process, and help achieve that velocity plan when it comes to the actual delivery.
Question: I am very concerned about 3rd party vendors being able to keep pace. McAfee HIPS/Endpoint Encryption and Beyond Trust Power Broker are two long poles in my enterprise tent at the moment…can’t do anything until they provide updated versions of their software.
Answer: This is a very valid and common concern, both on the application side, but also on the hardware side. Application vendors can work with Microsoft in the early phases of release development, but it is only once that release is finalized that they can fully certify their applications. The reality is that there is not a lot of time to do this before a new release comes out. The only way to really guarantee that compatibility will be there out of the box would be to standardize on the Microsoft tooling as that tends to get updated along with the OS.
Vendors can then certify their applications on the Windows Ready platform (which also feeds into Windows Readiness), and Microsoft are pushing vendors to do this, but there are so many applications and versions out there that it will take a huge amount of time.
Unfortunately, there is no easy answer to this problem – each organization must push its application vendors to certify early, and if the application requires an update, to get that information out quickly so that the deployment plans align to any new procurement/licensing requirement.
Question: Can you combine application readiness and upgrade by location in the ring approach?
Answer: Absolutely. Deployment rings are simply logical placeholders for grouping assets to be migrated. If your feature update rollout needs to be by location then we would advise that your deployment rings are location-based. The critical element is to have tooling in place that can show you the apps readiness for your location and the workload required before you can complete the rollout.
As we know (see the previous answer on velocity deployment), a location-based approach may not be the most efficient way to get the rollout done quickly since you may need to drive more application readiness earlier on in the process. This is because every application for that location needs to be ready before you can close the ring. It’s an example of why tools like Juriba Dashworks are so critical to managing update success because they can use logical groups to help with scheduling, but also pivot that data based on location (and/or business unit) to show how ‘ready’ assets are within those groups.
Commonly for the initial deployments, customers will make some significant changes to their deployment rings as they figure out what they need to do first, and how this initiative will progress in the most efficient fashion.
Question: How could someone get rid of old hardware in the organization which doesn’t support Win 10? Do you have a strategy?
Answer: Hardware tends to be refreshed either because it is out of lease or warranty cycle, depreciation has completed, or the organization has ‘sweated’ the asset as far as it can. We also have another component which is the hardware no longer supports Windows 10 because of a driver support issue, or simply that Microsoft or the vendor no longer support that device from release version x.
In this instance, rather than performing an update, the machine must be replaced. We would always advise that devices are kept within lifecycle to avoid these issues. At replacement time, we would typically investigate whether new platforms such as VDI might be a better alternative from an ROI perspective.
In order to discover which devices will and won’t work with Windows 10, you can use a tool like Windows Readiness in conjunction with vendor support statements from your device manufacturers who also provide tools to help with this diagnosis.
Question: Can you give me an example of Phase releases deployment concept?
Answer: Phased releases are where you split your assets across more than one Windows 10 release version. For example, if you were managing 10,000 devices, you might decide to put 5,000 on version 1703 and 5,000 on version 1709. You would the skip a release, so the 1703 devices would move to 1803 and the 1709 to 1809. This reduces the amount of update work in terms of volume of machines but increases it for everything else because you are introducing co-existence into the environment.
The strategy is best used where you have large, and very separate business units, or you simply cannot achieve a full update for every device within the Microsoft support lifecycle for that version.
Please refer to part 1 of this Q and A series with Barry Angell from Juriba and 1E’s Dave Fuller.
