Sorry about the last of a new posting recently, I'm busy working on a new project here at work.
I'm also doing some work on SP1 for Win7/R2, we have a couple of cool features coming with that release. So, does anyone have any topics they'd like me to cover? If so, post them in the comments and I will work on them, otherwise, I'll have a new post shortly with something new I've seen.
Is the Servicing Stack bug from Vista fixed, that packages are installed which can never be used?
Example. Install Sp1 and remove the old RTM files with DISM. So, when you now install an update which is for WIn7 RTM and Sp1, does the Servicing Stack install the RTM files too like it was in Vista? Or does the Sp1 Servicing Stack still has this issue?
I'd like a discussion of connecting to network printers (on a print server). I'm having a tough time automating the creation of these printers. I can create them one by one, but not via a batch file.
Andre: I'm not sure I follow what you're saying here. So let me take a shot at it and we'll see if we're on the same page. I'm assuming that what you're asking about is the installation of RTM bits post an SP1 installation for a new feature/role installation. If thats the case, there are scenarios when that might happen. For example, let's say you havent installed any of the Games feature for Vista. Later, you install SP1 and also run VSP1CLN, thereby pinning the installation of the service pack and making it non-removable. Then you decide to install the Games packages. If you did this and only a portion of the packages that make up that overall games feature were updated to SP1, then you have some files on SP1 codebase and some on RTM codebase (as determined by file version). Is that what you're asking? If not, let me know and I will help you if I can.
Hank: I'm the last person you want advising you on network printers <G>. However, I will send this out to the performance team internally here and see if they can't work on getting a new blog worked up that covers this topic a little more for you. Their blog is located here: blogs.technet.com/.../askperf
1. Install Vista Sp1 (integrated ISO)
2. install updates which apply to Sp1 and Sp2 (cumulative IE7 update)
3. install Sp2
until here everything is ok. servicing stack detect the Sp2 files from the IE8 update and use them.
great improvement over the ugly XP setup.exe which overrides everything.
4. now run compcln.exe to remove the Sp1 files.
NOW THE BUG occurs.
5. install a new update which applies to Sp1 AND sp2. The servicing stack still installs the Sp1 files too. But why? Those Sp1 branch files are never used again, because the Windows is now fixed to Sp2. removal of Sp2 is removed. We can't go back to Sp1. So why are all the Sp1 branch files stored in WinSxS folder? All those Sp1 files let the WinSxS folder grow too much. This is an huge issue if you have a SSD with 40-60GB.
Is this fixed in Windows 7 Sp1? If not, why? For a normal HDD this can be ignored, but not for SSD users.
is this so complicated to understand?
Thanks, I see what you're getting at now. Basically, the answer to this in Vista is that the list of files pinned by COMPCLN is a hardcoded list. We wont remove the any payloads outside of that listing, and that would include SP1 binaries that are included as part of a fix.
It's different in Windows 7 because of the way we handle servicing for MUMs up front. But that behavior is by design in Vista.
ok, so when Windows 7 Sp1 is out and I remove the old RTM backup files with DISM (or use an integrated Sp1 Media to setup Windows 7 with Sp1) and I install an update which applies to RTM and Sp1, the RTM files are no longer installed? This is all I want to know. I've submitted this on connect several times, but never got a rel answer.
I still have 2 minor servicing issue:
1. extracting updates from the CAB with expand makes the files unsigned.
2. offline integration of updates with pkgmgr/DISM causes that the date values are not correctly set. The values from the _manifest_.cix.xml are not applied to the new created files. When you install the update online the file dates are correct.
Fixed in Windows7 Sp1, too?
ok, some things left.
Why is th SP1 still not slipstreamable? It works for Vista SPs (after disabling the blockers in the mum and later changing registry settings in the CBS key) when you integrate the Sp into a fully configure N-1 image (when N stands for the Sp level). So integrating Sp1 into RTM works. But when Sp2 into an Sp1 slipstreamed image breaks the install.wim. But using a Sp1 ISO, the Sp2 slipstreaming works fine.
Will this be fixed in Windows 7 Sp2?
next thing, can you add better error message to WUSA.exe? "Doesn't apply to your PC" is the worst message ever. The question is why doesn't it apply. I look at the update.mum and the manifest files, to see if I have the parant packages installed and I look if I have newer updates installed.
So, can you please add message like :"Update can't be installed because if applies to x86/x64/ia64" and "Update KB123456 can't be installed, because Update KB654321 already includes it".
So, every user can see why an update can't be installed.
ok, last thing:
can you change the Servicing stack to only keep the most recent version of an update? I think it doesn't make up any sens to store all obsolete files in the WinSxS folder, For expamplce, it is useless to store all old files from cummulative IE updates. Remove all older IE updates and only keep the latest one.
This also keeps the WinSxS folder small.
I have an idea for a new topic.
I wrote a guide to determine DPC/interrupts issues with xperf (www.msfn.org/.../index.php). But how do I get the cause if the driver is not shown. Instead you see "UNKNOWN" and addresses (0x8xxxxxxxx which tells me this is a kernel driver). I would like to know how I can diagnostic this. Can you make a topic which discusses this?
I agree with Andre's suggestions about: 1. More detailed error messages. 2. Freeing up more disk space actively (updates delete older files especially files for older cardinal points). From above discussion, I understand Windows 7 (when we come to its SP2 in the future) won't store SP1 binaries in WinSxS if an update that applies to both SP1 and SP2 is applied? This "problem" exists only for Vista? Still we would love the /nobackup ability back in its entirety. The servicing is what increases the disk footprint of the OS by leaps and bounds over a period of time. You at least need to change something to make sure only the most recent files are stored and all older files are deleted.
Ok, sorry I havent gotten to these in a couple of days...I'll answer these all as much as I can:
1. Why is th SP1 still not slipstreamable? Mainly this is due to the way the SP installs and the part the servicing stack plays in all of it. We'll just say that it has to be done in the current fashion because it needs to be a very ordered process and leave it at that.
2. Will this be fixed in Windows 7 Sp2? Honestly, I dont know. I know its come up several times.
3. Can you add better error message to WUSA.exe? We have in Windows 7. You should now see messages that say more intuitive things to the user when they already have an update installed or the architecture is wrong. If you see one in Win7 that still gives "Does not apply" let me know and I will look into it.
4. Can you change the Servicing stack to only keep the most recent version of an update? In short, no. We need to keep the old stack around for updates that were written to that stack, for example, RTM bits. This is used a lot in deployment scenarios.
5. Can you make a topic which discusses this? I'll think about this. I would have to do some work on getting all of this together and I'll need to see what kind of time that would take. So definately maybe <G>
6. Still we would love the /nobackup ability back in its entirety. I'll bring this up to the product group.
1. Slipstream can be done when the source is a fully configured image. In this way the servicing works. So it looks like a bug in the servicing. My point is, that the bug happens because the WIMfiler driver mounts the instal.wim incorrectly which causes that updates are pending (if the hardlinks can be updated). You should look at this. In my opinion this is the root cause of the slipstream issue.
3. WIn7 only has the error message when the update is already installed, but not if you try to install an update which installs older files:
Install a new VM and install MS10-071. When you now try to install MS10-053 you get "doesn't apply". But you don't know why.
4. why? Why should we keep the files from MS10-053 if you install MS10-071? MS10-071 replaces MS10-053, so the files from MS10-053 are useless and only blow up the WinSxS folder.
5. do you mean the xperf thing?
what a bout the online/offine date issue. mount a wim and use DISM to integrate the update. Now install the WIM and look at the file dates. They are set to the time when you integrated the update. Now install a update with wusa online and check the file dates, they match to the dates shown in the kb article.
Thanks for the comments. I understand your points, some of them are very valid. I'll look into the applicability for things like the security updates, we should be doing a better job of supercedence there. As for the xperf thing, yes, thats what I was speaking to.
As for the date piece, as I stated previously, we dont care about the dates. We care about the versioning on the files. I know that people in the past used to rely on dates to determine applicability and installed version but this wasnt a good practice in downlevel OS and its an even worse one now for the reasons you've correctly stated.
ok, the date thing is a minor bug, but still a bug. If you don't care about dates, remove the values from the xml and also don't apply them when installing the updates online.
the space issue is a really important! Please understand this. Don't repeat the mistakes from Vista over and over again. 60% of the users are still on XP If they now see the growing WinSxs folder under 7 ,too they stay at XP! Fix it NOW, don't ignore it as you did in Vista. Please look at the telemetry data. How many people remove a cumulative IE update and go back to the old version? Also give better error messages. This is also very important. I see this often in the answers forums. People don't understand why the get messages "Don't apply to your PC".
What about the servicing stack update on WIndowsUpdate. Why do you rollout this RC version?
About the xperf thing. What do you want to know? I posted a link where I wrote the guide and I was able to help a lot of people. But some have UNKNOWN as cause. I want to know how to see which driver is it. Because all other
I know for a fact that members of the product teams within Microsoft read my blog specifically for the comments like what you have and it does generate internal conversations about the best ways to address issues moving forward. Obviously, its a delicate balance of getting things right, but we're trying.
About the xperf portion, I know what you're asking for, I personally just dont use xperf that much, thus the time commitment from my end would be pretty high to work on figuring out what you're seeing and why it would happen. I am going to ask around and see if some of the other engineers who regularly use xperf might have some ideas.
my last post was truncated. I wrote a bit more.
Ok, where can I ask about xperf? All other blogs seems to be dead. You are the last active blog where you get response when you make a comment.
What about the servicing stack update? Why is it offered on WindowsUpdate?
the users have conspiracy theory about it that is is malware. Does it mean the servicing stack is ready and no changes are made?
My idea is to add a new entry to the update.mum to <remove superseded updates =true"/> to control which updates can be removed and which not. It makes sense on updates like the cumulative IE updates.