How AI is Making Endpoint Management Easier

News

There is something a little odd happening in many companies right now when [...]

Read More

5 Items that Explain Total Experience (TX)

News

Total Experience (TX) is a concept that many business and technology leader[...]

Read More

Optimal Windows-as-a-Service Management Tool Stack

News | David Butler-McAllister | January 1, 2017 | 1560 Words

Time for an upgrade management system that works for you.

Efficiently managing Windows-as-a-Service upgrades is difficult. It’s for a good reason.

Optimal Windows-as-a-Service Management Tool Stack

  • Business Applications Layer
  • Applications Packaging Mechanism: need to be packaged in a certain format depending on what you want your end result to be.
  • Testing Mechanism: to be able to test various product types and versions of those products.
  • Deployment Mechanism: The delivery system of how you’re going to deliver those applications, e.g., Active Directory groups with SCCM top sequences or it could be your own deployment system.
  • Access Agent: manage and understand every version of the build that’s out there and reboot all the machines and quick start an Orchestrator
  • Underlying infrastructures around virtual machine technology ((combination of machines in the Citrix environment, an VMWare environment or an Azure Hyper-V Microsoft environment) = mechanism to build physical machines, e.g., virtual machines, laptops, hosted desktops

On each side:

  • Orchestrator = orchestrate how to run a build, e.g., create a build, install a build, install the core components of the applications over the top of the build, install any post-build apps you want to configure to your particular environment (Citrix, VMWare or Microsoft)
  • Evergreen IT Project Management System like Juriba: central command and control, a repository of life cycle management data, etc.

You need to be able to test your products and versions and have a version at request application of life cycle management control of your version of your testing of applications across the different build types.

Behind all of that as well depends on what channel you might be on, the long-term branch or short-term, whatever different branches. Then, the combination that wraps the whole thing together would be the different styles of deployment rings that you might be able to manage those sets of deployment rings. Whether it’s the first 5% of the organization based on low risk, low usage of apps. The next 10%, which is a bit more high usage of apps, a bit more riskier department, then withdraw the scout people once they’ve already gone through the 5 and 10%.

It’s massive. It’s almost like I might need to wipe something out. There are various technologies but it’s almost like trying to keep it simple as well because there are so many different technologies and moving parts. The best way to describe it would be the fundamentals over how to build a machine, how to actually do application tests and retesting, and what are the different infrastructure components and options, whether it’s a Citrix route, a VMWare route or a Microsoft route. Then, whether or not you want the different platform types, whether it’s physical hardware, virtual hardware, laptops, moonshots, which are hosted desktops, physically kept in a data center. Then, how you can actually manage from one build release to the next and then repeat test application.

It’s almost like a business process flow, a technical infrastructure diagram flow and then the operational model to how to actually manage in the release cycle, the infrastructure side of things based on the infrastructure choices and what’s out there. To five and 10% deployment ring, the way of doing things. Is such a massive topic. Is a huge thing. There are various, excuse me, other component parts amongst all your different choices of whether you do digital signatures and application weightlifting and all the security component pieces. Whether you do credential guards which often on is a cause and desktops or whether you just have it switched on on laptops because they’re more vulnerable.

Several other different choices around how your applications would work and how the testing would work for applications. There’s another spin-off site for the whole thing around the browser of choice. Whether or not you just stick with age, whether you stick with all of them, whether you go for two browsers of three, four, whether you have Chrome and Firefox as well integrated. Many companies will have tertiary browsers that have three to four browsers. Just so they have all the other different security reasons why some apps would and won’t work and then retest them across from build, edge is always been enhanced.

Various streams towards them, it doesn’t matter. I scrambled on, there’s all sorts of stuff in there. It’s such a big, almost like breaking down into three different sections whether it’s the infrastructure choices, your business, or processes which do your rollout and then your operational piece about how you retest a lot at like local management. Then we’re going to have to join in together to create the whole Windows as a service flow.

Hannah: It’s like we actually can’t build because there are so many variables and here are the variables that you need to check off. Okay, I’ll pick this apart. I will try to visualize it in in three. You know how we used to draw like 10, 15 years ago? The saw stack or an infrastructure stack as a service? Maybe I can do it like that because it was infrastructure as a service.

David: Yes, it would work by that. It’s almost like you’ve got your networking layer, your infrastructure, your application layer. You could call it out like that. Then you could do where the business processes have to lock in against the different elements of it. Once you’ve got a lot of infrastructure choices made, it’s just your repeat part against the top section of the bill change around the OEM above it or the ends or physical desktops, whichever way you go. But the actual machine management above the infrastructure layer. You’re building in blocks, right? And the infrastructure layer down below, then you’ve got your building blocks ready for your kit above. You have a parallel process of how operations would actually manage moving you, from one building layer to another. In between, there’s no operational process or product owner process of retesting and stand that the apps work okay. There’s so many gauches with this. We’re seeing it already in Morgan Stanley, a load of applications, as an example, was signed off on 1709 and then they completely broke on 1803.

We thought it was Microsoft and it turned out to be a vector defend point which is a security tool, which whitelist and blocks applications from installing. It was a version of defend point actually blocked a suite of applications from SAP from working. Now, we’ve got a new version of a vector. There’s a wasn’t a policy. Wasn’t like an XML Whiteley. It was just the actual product itself stopped and blocked some applications working. We thought it was the operating system and it turned out to be a core components security component actually blocked a load of that from working.

Some horrible stuff going on out there between the old versions and versions, different versions of core component products on different versions of Windows as well. Things are just moving so quick. Microsoft is pushing the boundary too hard, too fast. All these other companies can barely keep up with their own build cycles, to come back different probably changes to the underlying systems of them, what Microsoft has changed over time, and they’re hiding stuff all the time as well. They’ve taken out support for wind stock software modem connected to your software, they’ve taken it out between 1709 and 1803 and no one knew anything about it. That blocks an app, actually, firewall stops working. There’s all sorts of little gems that go on to every build release. The windows service pack can only combat it if you do the retesting. You build such a unique system to help to repeat build and repeat test. That is going to get a lot worse I think.

Hannah: We’ve actually seen that they just delete content from their blog and from their website without redirecting it or without actually saying that they deleted it. They keep on changing release dates, we keep track on screenshots of these and they just randomly change it and we’re like “Yes”. They’re hiding a lot of things. I’ll give this a shot. I might send you a [crosstalk]

David: Yes, fine send me anything over, it’s going to be a tough one. Send me what you can and I can have a look. I can even see if I can draw something up to help as well, maybe. The other one you mentioned was, what was it again? I thought that was it, wasn’t it? The actual Windows Service pack. We can have a look. I can have a look and see if is more could have done it, because they go through a whole process at the moment of trying to build out an evergreen modern of Windows service model. I’ll have a look at some of the documentation that’s been dealt at the moment, just to get my mind back into gear on some of the other sides of it that I don’t get involved in so much and that might help out. I’ll see if I can grab some ideas.

    UK

    Access IT Automation, No.1 Royal Exchange,
    London, EC3V 3DG

    USA

    D-300 Camelback Square, 6991 E Camelback Rd,
    Scottsdale, AZ 85251.