Windows 10 vs Windows 7
-
@PhlipElder said in Windows 10 vs Windows 7:
We also have a lab set up in the cloud for the same reasons for those that do not have any on-premises gear.
You have customers with cloud and an MSP but not computers to use? Do you mean that they all work from phones or iPads? Or they all use their home equipment and don't have it managed?
-
@scottalanmiller said in Windows 10 vs Windows 7:
@PhlipElder said in Windows 10 vs Windows 7:
There is no reference on my part for a SMB to have their own lab.
Whether an SMB's IT department has a lab, or their MSP's has a lab on their behalf, the cost of the lab is the same. The overhead, needs, and value all remain the same.
Yes, numbers wise for the equipment but in a MSP setting that lab is paid for across their clients that pay them to manage their infrastructure. Different kettle of fish.
-
Don't get me wrong, testing is a wonderful thing. Just like backups. But it is also important to keep perspective. What's practical and sensible in the enterprise or even a 500 person shop isn't always sensible in a 5 or 10 person shop. The world is very different. And small shops make up the majority of businesses.
And Microsoft already has labs and does testing. They can't test our exact environments, but small companies often can't do that anyway. A shop of 30 might easily have eight or ten different configurations. Uniformity is often very difficult in small shops. So let's say that they have 10 configurations. That would require ten pieces of hardware in a lab to do the most basic testing of patches for that hardware alone. And you only get that level if you maintain software uniformity. If you have ten different pieces of hardware types, and three different OS or application combinations, it's not completely impossible to have the need for thirty testing harnesses for thirty people. In an enterprise, this would never be a risk. In the SMB, it's not crazy at all to imagine it happening.
Even at one testing device for every three users, that's really tough to cost or time justify. That's a lot of lab time and equipment, that you need to be using continuously, in a shop where the risks of not testing are.... pretty close to zero.
That's where you really need to start. But a dollar sign on the risk of patching. Then show how testing can mitigate that risk by enough to cover its own costs.
-
@scottalanmiller said in Windows 10 vs Windows 7:
@PhlipElder said in Windows 10 vs Windows 7:
We also have a lab set up in the cloud for the same reasons for those that do not have any on-premises gear.
You have customers with cloud and an MSP but not computers to use? Do you mean that they all work from phones or iPads? Or they all use their home equipment and don't have it managed?
This one is tough to answer as we have clients that run in our cloud, public cloud, or hybrid mode that use a wide variety of devices to connect to their services/apps/whatever. It really depends on the way they are set up.
But yes, we can manage things for them as well. Ever try? Especially with a plethora of cloud services being delivered to one client across many devices/sites/places? Ugh ...
-
@PhlipElder said in Windows 10 vs Windows 7:
@scottalanmiller said in Windows 10 vs Windows 7:
@PhlipElder said in Windows 10 vs Windows 7:
There is no reference on my part for a SMB to have their own lab.
Whether an SMB's IT department has a lab, or their MSP's has a lab on their behalf, the cost of the lab is the same. The overhead, needs, and value all remain the same.
Yes, numbers wise for the equipment but in a MSP setting that lab is paid for across their clients that pay them to manage their infrastructure. Different kettle of fish.
That's what I was explaining - you can't do that. That's what Microsoft is doing already. So we have one of three cases...
- You have an MSP that enforces hardware and software uniformity amongst all (or a lot) of their clients. While these exist, they are rare and don't apply to the normal world. It's a super rare customer that can let their IT "pool" dictate their setup. If you don't, then your lab isn't testing for them and is just duplicating Microsoft's own lab.
- You have a lot of hubris and believe our labs are way better than Microsoft's.
- You truly believe Microsoft is incompetent to a degree that it's unthinkable that you'd use them.
So I assume you are in group 1. That's great. But your experience applies to essentially no one. No ITSP, no internal IT, and no normal MSP can do that and call it a testing lab. It's a lab, technically. But it's not a lab in the sense that we are discussing here where you can test patches for the customer's unique environments which is the point of testing after Microsoft has already done the generic testing in vanilla environments.
-
@PhlipElder said in Windows 10 vs Windows 7:
@scottalanmiller said in Windows 10 vs Windows 7:
@PhlipElder said in Windows 10 vs Windows 7:
We also have a lab set up in the cloud for the same reasons for those that do not have any on-premises gear.
You have customers with cloud and an MSP but not computers to use? Do you mean that they all work from phones or iPads? Or they all use their home equipment and don't have it managed?
This one is tough to answer as we have clients that run in our cloud, public cloud, or hybrid mode that use a wide variety of devices to connect to their services/apps/whatever. It really depends on the way they are set up.
But yes, we can manage things for them as well. Ever try? Especially with a plethora of cloud services being delivered to one client across many devices/sites/places? Ugh ...
Right, but if you aren't testing and replicating all of those end user devices - that's not testing
And we are back to "just patch and don't test", right?I get why it is hard. That's my point. My customers have a million end points. All unique. There's no uniformity, not within a customer, let alone across them. Nearly every user has a totally unique situation. Even when the hardware and software are the same, the networking, ISP and other factors can introduce differences that might matter, too.
-
@scottalanmiller said in Windows 10 vs Windows 7:
@PhlipElder said in Windows 10 vs Windows 7:
@scottalanmiller said in Windows 10 vs Windows 7:
@PhlipElder said in Windows 10 vs Windows 7:
There is no reference on my part for a SMB to have their own lab.
Whether an SMB's IT department has a lab, or their MSP's has a lab on their behalf, the cost of the lab is the same. The overhead, needs, and value all remain the same.
Yes, numbers wise for the equipment but in a MSP setting that lab is paid for across their clients that pay them to manage their infrastructure. Different kettle of fish.
That's what I was explaining - you can't do that. That's what Microsoft is doing already. So we have one of three cases...
- You have an MSP that enforces hardware and software uniformity amongst all (or a lot) of their clients. While these exist, they are rare and don't apply to the normal world. It's a super rare customer that can let their IT "pool" dictate their setup. If you don't, then your lab isn't testing for them and is just duplicating Microsoft's own lab.
- You have a lot of hubris and believe our labs are way better than Microsoft's.
- You truly believe Microsoft is incompetent to a degree that it's unthinkable that you'd use them.
So I assume you are in group 1. That's great. But your experience applies to essentially no one. No ITSP, no internal IT, and no normal MSP can do that and call it a testing lab. It's a lab, technically. But it's not a lab in the sense that we are discussing here where you can test patches for the customer's unique environments which is the point of testing after Microsoft has already done the generic testing in vanilla environments.
I see your point to some degree and yes, there will be threads not covered by our testing. But, the bulk of the systems we manage would be. And, we do find value running through the testing as we do indeed find problems or bugs that we can then be prepared for when it comes time to either patch or skip until things are fixed.
That's what www.patchmanagement.org is for. It's a great resource.
I suggest watching those general statements though. They come across as pontificating at times.
-
Example... I'm doing updates for an organization with 300 managed desktops right now. At most, we might have 3-4 that are uniform in any group. Having a lab to test all of their updates would come very close to needing to have one lab device for every user. 285 of their users work from home. 260 of those use their own devices, but we support them. Of the 30 that we provide the hardware, we are pushing for more uniformity, but it's a broad space. We are up to 3-4 that we've got similar. There were a few clumps like that in the past, but sporadic hiring and replacements and promotions have led to heavy disparity.
It seems that at that size we'd be able to do testing effectively. But really, we can't. Once we get uniformity up to 20+, it'll be on the radar. But really, the risks are super low. Data is all backed up remotely and rebuilding the machines is not a huge deal. So we have to weight the cost of recovery against the cost of testing.
-
@PhlipElder said in Windows 10 vs Windows 7:
@scottalanmiller said in Windows 10 vs Windows 7:
@PhlipElder said in Windows 10 vs Windows 7:
@scottalanmiller said in Windows 10 vs Windows 7:
@PhlipElder said in Windows 10 vs Windows 7:
There is no reference on my part for a SMB to have their own lab.
Whether an SMB's IT department has a lab, or their MSP's has a lab on their behalf, the cost of the lab is the same. The overhead, needs, and value all remain the same.
Yes, numbers wise for the equipment but in a MSP setting that lab is paid for across their clients that pay them to manage their infrastructure. Different kettle of fish.
That's what I was explaining - you can't do that. That's what Microsoft is doing already. So we have one of three cases...
- You have an MSP that enforces hardware and software uniformity amongst all (or a lot) of their clients. While these exist, they are rare and don't apply to the normal world. It's a super rare customer that can let their IT "pool" dictate their setup. If you don't, then your lab isn't testing for them and is just duplicating Microsoft's own lab.
- You have a lot of hubris and believe our labs are way better than Microsoft's.
- You truly believe Microsoft is incompetent to a degree that it's unthinkable that you'd use them.
So I assume you are in group 1. That's great. But your experience applies to essentially no one. No ITSP, no internal IT, and no normal MSP can do that and call it a testing lab. It's a lab, technically. But it's not a lab in the sense that we are discussing here where you can test patches for the customer's unique environments which is the point of testing after Microsoft has already done the generic testing in vanilla environments.
I see your point to some degree and yes, there will be threads not covered by our testing. But, the bulk of the systems we manage would be. And, we do find value running through the testing as we do indeed find problems or bugs that we can then be prepared for when it comes time to either patch or skip until things are fixed.
That's what www.patchmanagement.org is for. It's a great resource.
I suggest watching those general statements though. They come across as pontificating at times.
Something else to think about when looking at this. We have a lab (we meaning as an ITSP) and we have, for example, Windows 10 in it. We "test" patching there first, we are always patching there. So that's a form of a lab.
Then from the lab machines, we patch our internal non-prod Windows machines (jump boxes, proxies, etc. used by IT, not customers.) That's a form of lab.
Then we do patching across customers with unique patching and planning on their own. But as we do updates, each machine while production itself, acts as a lab for the next machine and/or customer in line. It's not like every machine, at every customer updates at the exact same time. If we are going to find issues, we are most likely to see it early. The later something comes up in the process, the less likely it is to have ever been found in a lab. The larger the pool of customers, the smaller the risk to any given customer given the process. So as odd as it sounds, the larger the total pool the lower the value of a lab (but the lower the cost per customer.)
So if we aren't in a position of needing to test unique configurations, but only testing the patching process in general, then having a lab is easy but not really addressing the big concern (MS tests this and it works presumably thousands of times before we ever see it.) But having processes like we do, as loose and simple as they are, actually go a really long way to minimizing actual risk, while keeping the cost of that mitigation really low.
-
@G-I-Jones I like Windows 7 a lot, but since the things are moving forward we all will use something new instead very soon. Just remember how people wanted to stay on Windows XP, but finally updated their OS. The same will happen with Windows 7 and most of users will move on Windows 10 or will choose another option
