…or lack thereof? I wanted to add that in the title as well, but unless there is a competition for the longest blog titles, I don’t want to waste my skill right now. In this post, we are going to discuss if there is any relationship between a SUG and a Deployment Package.
What am I talking about?
If you clicked on the post after reading the title, you probably know what I’m talking about. But for those who don’t, I’ve got you covered as well.
Software Update Group (SUG) is like a container for Software Updates in MEMCM. Container for the metadata, and not the actual updates themselves. That’s where a Deployment Package comes into the picture.
Deployment Package, as I mentioned before, is where the actual binaries of the updates are downloaded and stored. Shall I call it a DP from now on? Unfortunately, that acronym has already been taken up by the big bad Distribution Point. Poor little Deployment Package. Let’s call it DPack. Feeling better now? Let’s move on.
The usual process of deploying software updates through MEMCM involves creating a SUG, downloading the updates within that SUG into a DPack, distributing the content of the DPack to the DP, and then deploying the SUG to the machines.
Can two SUGs contain the same update? Yes.
Will the same update in different SUGs be downloaded twice in a DPack?
Can an update be installed if it is present in a different DPack than what the SUG is “linked to”? These are some of the questions and confusions that come up.
Let’s find out.
Downloaded Twice?
In order to verify this behavior, I did a simple experiment to download the same update into four different deployment packages to see what happens. The results were as follows:
The first time, the update binaries got downloaded.
Every subsequent attempt, it automatically detected that the same update has already been downloaded before, and instead of downloading it again, it created a hard link for that file.
If you try this yourself, you’ll see that there are multiple files being downloaded and each of them is occupying disk space. Don’t get confused by that. It’s a little misleading.
For the current scenario, this is what the disk space utilization looks like:
Looking at the folder properties (left screenshot), it seems that the updates got downloaded four times and are occupying four times the space. But if you check the Drive properties (right screenshot) instead, you’ll get to know the actual disk consumption. Only one copy was downloaded, and the rest are hard links.
SUG “Linked to” DPack
Let me start by saying that there is no relationship between a SUG and a DPack. If you try to create each of them individually, you won’t find a reference to the other. If you open the properties for either one of those, you won’t find anything that relates to the other.
Then why the confusion in the first place? It’s because the traditional steps followed in order to deploy Software Updates either manually or through ADR require you to create a SUG first and then a Deployment Package. This leads some to believe that the SUG is related to a DPack.
The first clear indication that that’s not the case comes when you’re trying to deploy a SUG for an update that’s already downloaded. It won’t ask you for DPack details then.
If that does not convince you, I have one final test. I created a SUG for an update that was not downloaded previously.
While deploying, it asked me for the DPack and I created one.
The final step before completion involved the download of the update binaries into the DPack.
Now I have one SUG and one DPack.
Next, I created another DPack for the same update. As you may know now from the previous section, this is not going to download the update again, but create a hard link instead.
Then, I deleted the first DPack (KB5016629 DPack) that got created while creating the SUG.
Now if I move to the machine where I deployed that update, we see that it’s available in the Software Center.
Here comes the moment of truth. If there really is a relationship between a SUG and a DPack, the update should not download and install as we have deleted the DPack that got created with the SUG.
As you saw in the video, the update downloads and installs without any issue.
Summary
There are two things that I want you to take with you from this post:
- There is no relationship between a SUG and a Deployment package
- Updates are downloaded only once even if the same update is part of multiple SUGs and/or DPacks.
