none
When Will IE 9 Hit WSUS?

Answers

All replies

  • I've been trying to find out when IE 9 will hit WSUS

    Well, certainly not before it's actually a released product, so maybe waiting until that happens would be a first step. Do you know the Release Date for IE9?

    If history is any indication, it will be some period of time after the release before the product is packaged to support unattended installations via the WUAgent.

    I'm anxious to avoid automatically synchronising it as my environment currently auto approves update rollups and obviously don't want to do this with IE 9 until further web application testing is completed.

    Maybe the appropriate question here is why you are auto-approving Update Rollups to begin with? That certainly seems a risky practice. I don't see anything in that classification that isn't worthy of appropriate deployment testing before being rolled out to production systems.

    An inventory of updates released in this classification over the past year includes:

    • Daylight Savings Time updates
    • Silverlight updates
    • the Malicious Software Removal Tool
    • Internet Explorer 8
    • an April 2010 reliability update
    • and a January 2010 reliability update

    The volume of content is so minimal in that classification, that manually approving updates would not be a difficult task -- even in the most understaffed organization, and other than the MSRT, nothing in that list warrants automatic approval, IMHO.

    I submit that the best solution in this scenario is to disable that auto-approval rule, and engage with the console once-per-month to determine if any new Update Rollup content requires approval, and manually invoke the update approval.


    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2011)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    My Blog: http://onsitechsolutions.spaces.live.com
    Monday, February 14, 2011 6:33 PM
  • Thanks for that response very helpful. Not.

    You can safely assume that there is a reason for us synchronising update rollups, it's not your job to determine my business requirements.

    Wish I hadn't asked.

    Tuesday, February 15, 2011 8:48 AM
  • You can safely assume that there is a reason for us synchronising update rollups, it's not your job to determine my business requirements.

    Look. You came asking for a SOLUTION to a non-existent problem. Furthermore, while you posted the question, don't be so naive (or arrogant) to think that you're the only person who might be seeking an answer to this question. So my post is not just targeted to you, personally, but to ANY patch administrator who might be contemplating this same question in their environment.

    The fact is that the solution you seek is near impossible in the current conditions.

    Incidentally -- how did you handle Internet Explorer 8? This is how you would handle Internet Explorer 9 as well.

    Of course, you could remove the approval for IE9 as soon as it arrives, that's the only actual action you can take under the specified conditions, but that's certainly no guarantee of preventing the leak of IE9 onto some systems.

    It's most unfortunate that you didn't like the response, and you're right that it's not my place to determine your business requirements. In fact, I'm not trying to determine your business requirements, and if you have valid business requirements for auto-approving Update Rollups, then c'est la vie. I'm cool with that. But then you need to be cool with the ramifications of those decisions. One of the ramifications is that Internet Explorer upgrades will be automatically approved for installation in your environment.

    Bottom line, you only have THREE choices:

    • Remove the automatic approvals for Update Rollups.
    • Automatically approve Internet Explorer 9 when it is released to WSUS.
    • Try to remove the automatic approval when IE9 is released and hope you're faster than the WUAgent detection cycles.

    Aside from your business requirements, which I really do not have an interest in, the question fundamentally revolves around which is more important:

    • Absolutely preventing the deployment of Internet Explorer 9 when it happens
    • Investing a minimal amount of effort to manually approve the occasional update released into this classification as necessary

    It's your decision. I don't care what you choose. I'm merely presenting the realistic options. You decide.


    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2011)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    My Blog: http://onsitechsolutions.spaces.live.com
    Tuesday, February 15, 2011 6:17 PM
  • I've been trying to find out when IE 9 will hit WSUS (and normal Windows Update) but haven't been able to.
    The answer has not been published by the IE team yet. We don't know. Nobody knows -- perhaps not even the IE team!
    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2011)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    My Blog: http://onsitechsolutions.spaces.live.com
    Tuesday, February 15, 2011 6:19 PM
  • Don't they release a Blocker tool anyway prior to distribution of new versions of IE? I recall they did that for IE8.

    Tuesday, February 15, 2011 9:18 PM
  • Why couldn't you have posted that first off? And as for implying I'm arrogant - it's outrageous. No wonder people are wary of posting in technical forums if this is the sort of high handed approach that they might get. It would have been enough to simply point out that I'd been reading the right links and that there wasn't a date yet.
    Wednesday, February 16, 2011 9:11 AM
  • Thanks djdanlib. I've already spotted this from the technet information I've been reading. As we run WSUS I'll be doing as Lawrence suggests above and suspending auto-synching of Update Rollups so it doesn't get pushed out. Next on my list is Win 7 SP1.
    Wednesday, February 16, 2011 9:21 AM
  • Don't they release a Blocker tool anyway prior to distribution of new versions of IE? I recall they did that for IE8.

    Yes, but it does not apply in the WSUS environment. The correct methodology in WSUS to preclude installation of IE is to:

    • Not Approve the update, and
    • Block access to WU/MU using policy.

    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2011)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    My Blog: http://onsitechsolutions.spaces.live.com
    Wednesday, February 16, 2011 9:18 PM
  • This assumes that your environment is using WSUS 100% of course. If this isn't the case....you might need both approaches.
    Tuesday, February 22, 2011 10:58 AM
  • This assumes that your environment is using WSUS 100% of course. If this isn't the case....you might need both approaches.

    This is the **WSUS** forum. We assume everybody who posts in this forum is using WSUS.

    Notwithstanding the point that I explicitly prefaced my statement with "The correct methodology in WSUS..."

    Are you just trying to be argumentative?


    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2011)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    My Blog: http://onsitechsolutions.spaces.live.com

    Tuesday, February 22, 2011 2:13 PM
  • I was just saying as this is the situation we face here, we do use WSUS but the environment we operate in means that there is no mandating that this is the case. Apologies if you took offence.
    Wednesday, February 23, 2011 5:23 PM
  • Thanks for that response very helpful. Not.

    You can safely assume that there is a reason for us synchronising update rollups, it's not your job to determine my business requirements.

    Wish I hadn't asked.

    "Look. You came asking for a SOLUTION to a non-existent problem. Furthermore, while you posted the question, don't be so naive (or arrogant) to think that you're the only person who might be seeking an answer to this question. So my post is not just targeted to you, personally, but to ANY patch administrator who might be contemplating this same question in their environment."

     

    I completely agree with Lawrence.  I came into this forum purely looking for IE9 related information, but reading his post led me to make sure Update Rollups were off (which they were).  His post helped ME to make sure I didn't have something set incorrectly.  I didn't have anything set incorrectly, but I'm always interested in someone else's suggestions, especially for Best Practices.

     

    Thanks Lawrence

    Tuesday, March 15, 2011 2:00 PM
  • This may go against forum policy but I wan't to say that Lawrence is a 100% correct here. If you follow Microsoft products, the trend has been a month or so of lag between the release and WSUS getting the update.  I think last time with IE8 it was a a few months.

    The original poster would need to understand that there is no tone applied when reading these posts and should not jump to conculsions.  Lawerence your follow up repsonse was the most professional thing I have read in a long long time.

    I glad people like you exists.

    Tuesday, March 15, 2011 2:43 PM
  • Wow, I've got to say I never expected to find such a heated topic on the subject!

    Though hopefully the information will be available soon, as MS has just released it to the web today.

    Tuesday, March 15, 2011 3:42 PM
  • Don't want to start a flame but... why should be so risky to autoenroll rollup updates?? IE8 apart, are we assuming that the guys at MS can f**k up the Daylight Savings Time updates???? :)

    Anyway, I'm asking because I really want to understand Lawrence's point of view to improve my knowledge on WSUS best practices.

    I surely cannot agree with the principle of manually approving updates just because the classification is so minimal.

    As in other discussions, too often the real situation of small/medium organization is not considered as it should: WSUS is a great tool even in small offices with no IT staff at all. As an external consultant for this kind of clients, I look for fire and forget solutions all the time: this way I can serve more clients and they can save up money requiring less time from me to administer their systems.

    Maybe the best solution is "target-dependant"...

     


    Dario Palermo
    Tuesday, March 22, 2011 10:03 AM
  • why should be so risky to autoenroll rollup updates?? IE8 apart, are we assuming that the guys at MS can f**k up the Daylight Savings Time updates???? :)
    Fundamentally, it's not that risky, Dario, presuming that the only updates in that classification are IE upgrades and DST updates. But no such guarantee exists, so the issue is not about the IE update or the DST updates, but about the unknown update packages that might be released into that classification at some point in the future. That is where the risk exists.
    Anyway, I'm asking because I really want to understand Lawrence's point of view to improve my knowledge on WSUS best practices.
    My point was that since the driving issue seems to be NOT auto-approving the IE9 upgrade, when it is released, that the appropriate solution to that problem is to remove the auto-approval rule for that classification. Given that in the past year only a handful of updates, mostly DST updates, have been released into that category, the impact of not auto-approving that classification is minimal, at best, and the workload to manually approve a DST update twice a year is likely also insignificant compared to the primary issue of IE9 leaking onto the organization's client systems -- which is, it appeared, most emphatically undesirable.
    I surely cannot agree with the principle of manually approving updates just because the classification is so minimal.

    In fact, from a "best practices" perspective, implementing any auto-approval rules is something that should be justified with a very specific business case, and should also be implemented based a combination of Product Category and Update Classification. For example, at one time (when they were being released) I had an auto-approval rule for Exchange Server and Update Rollups, so that the Exchange 2003 IMF updates would be auto-applied to my Exchange 2003 Server. Even that wasn't a no-risk proposition because there was no guarantee that an Exchange "rollup" wouldn't be released into the catalog.

    However, since Exchange IMF updates were Minor updates were immediately installable, and the server was configured to use AUOption='3', even if an update were to be auto-approved, it would never be actually installed without my consent, so the risk of the auto-approval rule was mitigated by the update installation policy configured for that particular server. 

    As in other discussions, too often the real situation of small/medium organization is not considered as it should: WSUS is a great tool even in small offices with no IT staff at all. As an external consultant for this kind of clients, I look for fire and forget solutions all the time: this way I can serve more clients and they can save up money requiring less time from me to administer their systems.
    And this point is where we'll differ, fundamentally, in terms of architecture of the solution for the stated problem. IMHO, for an organization looking for a "Fire-and-Forget" updating methodology, particularly small organizations, the better solution than WSUS-with-auto-approval-rules, is simply leaving those clients configured as Automatic Updates client, and implementing a proxy cache server, so that the AU content is cached one-time for local consumption. WSUS was not designed as a fire-and-forget solution, it was designed to enhance the ability of organizations to explicitly control the when and where of updates management. While WSUS certainly can be implemened as a fire-and-forget installation, that is not the optimal solution for that particular objective.
    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2011)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    My Blog: http://onsitechsolutions.spaces.live.com
    Wednesday, March 23, 2011 12:21 AM
  • I bet you'll recognize the following text ;)

    ---

    Currently Using Windows Updates or Automatic Update

    If you’re not yet using WSUS you may find yourself in one of two situations: One likely scenario is that you are—or somebody you’re paying is—walking around to each of the computers in your organization each and every month, and manually downloading and installing the updates. This method is advantageous in that you know, for certain, that updates are being installed, but it’s quite expensive in terms of time and resources.

    Or, perhaps you’ve taken a step beyond the manual, brute-force method, and you have Automatic Updates enabled on every computer in your organization. It either downloads updates and you install them manually later, or you have fully automated the use of Automatic Updates and the updates are installed automatically.

    However, you might not be actively monitoring the status of updates at all, or have only an overview of the update status of your environment at any one time. The questions to ask yourself are: Do you know whether the updates have been successfully installed? Do you know, for certain, that your computers are fully updated and protected from the things updates are designed to protect them against?

    Even more significantly, which of these methods are you using to ensure your Small Business Server (SBS) host server is updated each month? What will you do when the server that hosts all the e-mail, files, and Web sites that you rely on to be there every morning suddenly fails, because a critical security update was missed, or installation was delayed for days, or even weeks, because a more pressing business need took priority?

    What if you could have a fully automated system for ensuring that every computer in your organization was updated when you wanted it to be; if you could track the status of every computer without leaving your desk; and your total time investment was only a few hours each month? Or, more significantly, what if your monthly system maintenance cost was measured in hundreds of dollars, rather than in thousands of dollars? That system exists today. It’s called Windows Server Update Services (WSUS), and it’s free! If you don’t have it, and you’re a Small Business Server user, you need it—now! 

    ---

    The "Auto Update on all client" solution (with the caching proxy server to mitigate bandwidth usage) lacks reporting... a must for all administrators. And anyway, when using automatic updates we trust Microsoft blindly... why shouldn't we, instead, use WSUS and gain some more control over the process without changing the overall automatic updates system. Like a grey solution between the white "autoinstall ALL with automatic updates" and the black "autoinstall nothing and wait for an administrative action before install". Ok sure, WSUS will not be used to its full potential, but in some scenarios it's ok.

    And last but not least, which small size company can afford to have a test lab?? Without testing, you can only choose to apply or not apply every single update, maybe googling for reported problems, but in the end is a leap of faith... ;)

    Thanks for the reply, by the way!


    Dario Palermo
    Thursday, March 24, 2011 1:07 AM
  • Has there been any news on the WSUS relase of IE 9? I want to deploy to a few Windows 7 PC via WSUS to see what the install and config time is rather than deploying via GP or direct install.

    Thanks

    Wednesday, March 30, 2011 2:55 PM
  • I bet you'll recognize the following text ;)

    Yes.

    And your point is...?


    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2011)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    My Blog: http://onsitechsolutions.spaces.live.com
    Thursday, March 31, 2011 3:20 PM
  • A couple od replies ago you said :

     

    And this point is where we'll differ, fundamentally, in terms of architecture of the solution for the stated problem

     

    It seems to me that, in that article you wrote, you were offering the exact solution I gave to my clients. An update server with reporting capabilities and very little management time requirements: WSUS. That's all. Very little management time have to mean autoapproval (or "fast" manual approval) without a testing phase in most for the large part of updates (maybe exluding service packs or new produtcs like IE8/9 etc.). It's a common scenario, at least in the actual economy here in Italy: lots of small sized companies (I mean SMALL, "1 server and 5 clients" like or a little bigger).

     

    I completely agree with you that in medium/large sized company the business requirements are different and auto approval is often not the best choice.


    Dario Palermo
    Thursday, March 31, 2011 6:18 PM
  • It seems to me that, in that article you wrote, you were offering the exact solution I gave to my clients.

    I think, perhaps, that is because you are taking that "article" out of context. The first few paragraph you cited are the Introduction to a White Paper written primarily as a marketing tool targeted at the Small Business Server environment, where typically 100% of systems are still being updated via Automatic Updates, or worse, Windows Update on a hit-and-miss basis.

    The use of the phrase "...a fully automated system..." is not intended to be in the literal sense, but rather in the relative sense, given that the target audience is probably not even updating systems, in general. Further, the "article" also says "...when you wanted it to be..." and "...total time investment [is] only a few hours each month..." both statements being contradictory to the idea of a "totally hands off" system employing automatic-approval rules for all updates.

    The fact of the matter is that a properly managed WSUS environment, NOT using automatic approval rules, should only take a few hours per month of one person's time -- and it really doesn't matter what size of organization. TESTING is not included in that "few hours each month", because the only time investment required after approving updates for the test group is to check back in 24-48 hours to see if they installed, and inquire with the users of those systems to see if any issues are encounterd. For a small/medium business, that's measured in minutes, not even hours.

    My position is this: It doesn't matter what the size of the organization -- using automatic approval rules for ALL updates of any classification is not a "best practice" and it's a guaranteed invitation for more investment of time down the road when things blow up. For a contemporary example of this, take a look at all of the SBS environments being bitten by the Windows 7 Service Pack 1 update that got auto-approved by the customized versions of WSUS that are installed in SBS2003 and SBS2008.


    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2011)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    My Blog: http://onsitechsolutions.spaces.live.com
    Saturday, April 02, 2011 12:47 AM
  • Saturday, April 02, 2011 7:00 AM
  • The IE team has not been forthcoming as to when exactly it will show up on WSUS.  The Windowsblog states that it will start to come out on WU in Juneish.
    Saturday, April 02, 2011 7:01 AM
  • Ok Lawrence, we simply do not agree then. Anyway, I auto approve on variuos WSUS in various organization and had W7 SP1 deployed this way and had 0 issues. Maybe I'm a lucky guy. ;)

    I guarantee you that with auto approval I saved so much time even working out some issues from time to time. Never had a major crash in systems or applications in years.

    I also can't agree with the principle that, when it's marketing it's ok to make things shine and after solding them tell people that it's not exactly what was promised...

    And, anyway, the testing phase as you're proposing it is, excuse my words, a real joke. The more problematic softwares to test are the ones that users open once in a month, not clearly MS Office or the payroll software they use every working day. And in most cases the application would still run, having problems that will show eventually, far after your 48 hours test phase. And you're realying also on non technical user assessment... My average user can't tell the difference between os version and Office version, they keep telling me they have Windows 2007 (winXp and Office 2007, btw). Most of the time, I could reply to support calls with IT Crowd Roy's answering machine...

    Very few people have the time and the recources for a comprehensive testing phase that includes standard softwares, and I wouldn't define it a best practice (also in the 70-642 self paced trainik kit book, for an example, it is told that the testing should focus on custom apps compatability with deployed updates).

    Example: I had myself troubles with IE9 and the TMG 2010 Console. In the 7 days of testing IE9 on a test admin machine I simply didn't use that console and didn't even think that it could rely on IE. I was wrong and i found out only after deploying IE9 on the production admin workstations.

    The truth is, the only real benefit in manual approving in most of the cases is that you can save some troubles when Microsoft screws up some updates, like the Win7 SP1 and probably not by testing the updates on your own, but relying on online communities/forums where others complain about recent updates. ;)

    If I had Win7 killed by SP1 via WSUS, I'll blame (and, if possible, sue) Microsoft, not myself for not testing a major update that should have been tested carefully by the sw producer.

    Anyway, I know you'll not agree and I'm fine with it, in Naples we say "Ric' semp si, ca cap nun se ne car" (something like: always nod your head, it will not fall down).


    Dario Palermo
    Saturday, April 02, 2011 9:17 AM
  • You were lucky.  If you approved Win7 sp1 and it came down with other updates you had a real chance of hitting the c34 issue.

    You know why I don't let it auto approve?  Because why should I be part of the dead bodies of patching?  Even if you don't test, if you aren't part of the first wave of installs you benefit from someone else testing and being first.

    I'm testing IE9 right now and there's tweaks I've done, there's a shortcut I had to get working again.

    I wouldn't be auto approving either.

    Saturday, April 02, 2011 2:48 PM
  • In message
    <33ad8f35-320c-4966-94ea-c51a62e3aec9@communitybridge.codeplex.com>
    someone claiming to be MR_SPARKLE969 typed:

    Has there been any news on the WSUS relase of IE 9? I want to deploy to a few Windows 7 PC via WSUS to see what the install and config time is rather than deploying via GP or direct install.

    It's available in the catalog at this very moment, so you can either
    wait to see how long it takes Microsoft to add it to the regular WSUS
    deployment (my money is on Patch Tuesday in April or May, probably May),
    or you add the update in WSUS from the catalog right now and deploy
    today.

    Saturday, April 02, 2011 11:36 PM
  • Susan, aside from my bet to autoapprove W7 service pack 1 (to about 8 computers at my primary work location, a limited context), commonly what I think it's not worth autoapproving are service packs and new products, and I'll do exactly as you suggest: check the internet for problems encountered by the first wave of installs.

    But, honestly, it's unrealistic to propose to do that way for every little security update if you're in charge of not only system update deployment.

    And again, even waiting for others to find out problems, you can protect yourself only against major bugs. If I weren't looking for the exact problem I'm having with IE9 and TMG console, I'd never found out about it googling some generic "IE9 known issues". In this specific case, I think an "install and remove if not satisfied" policy spared me some time.

    At the end, managing updates is an hell of a responsability. If, and I'm not sure we should, we rule out autoapproval and the equally risking "manual approval without proper testing" (48 hours of no complaints isn't a proper test IMHO), a large number of small company should avoid proactive update deployment and stick with the rule "if isn't broken, don't touch it".

    Best regards


    Dario Palermo
    Monday, April 04, 2011 8:03 AM
  • In message
    <35a11935-86e7-48e5-924f-e62f288fc3e2@communitybridge.codeplex.com>
    someone claiming to be Dario Palermo typed:

    Susan, aside from my bet to autoapprove W7 service pack 1 (to about 8 computers at my primary work location, a limited context), commonly what I think it's not worth autoapproving are service packs and new products, and I'll do exactly as you suggest: check the internet for problems encountered by the first wave of installs.

    But, honestly, it's unrealistic to propose to do that way for every little security update if you're in charge of not only system update deployment.

    Why?

    I mean on one hand, millions of PCs out there get updates automatically
    directly from Windows Update, so using WSUS as a fancy cache and
    reporting system (auto-approving things you'll likely need/want)
    shouldn't be that scary.

    On the other hand, Patch Tuesday exists for this very reason.  Other
    than out of band patches (rare, and Microsoft will notify you if you
    subscribe), you only need to look (and test) new patches once a month.

    Not everything is released on a Patch Tuesday, but usually stuff that
    was released at other times can wait.

    FWIW, I auto-approve definition updates and similar, but manually
    approve everything else.  My testing isn't as thorough as I'd like, but
    it's better than nothing, and the 2-3 day delay before other computers
    get patched is usually enough to hear if there are any terrible
    problems.

    Monday, April 04, 2011 7:41 PM
  • I mean on one hand, millions of PCs out there get updates automatically
    directly from Windows Update, so using WSUS as a fancy cache and
    reporting system (auto-approving things you'll likely need/want)
    shouldn't be that scary.

    Infact, I usually auto approve "smaill-impact" (security patches, etc.) contents.

    And I'm embarassed to admint I believed that Patch Tuesday was every week... Shame on me!

    With patches released once a month, obviously it's possible to schedule at least "wait (for others to install) and see" phase for the small businesses that don't have resources on their own...


    Dario Palermo
    Tuesday, April 05, 2011 12:23 PM
  • Lawrence I will agree with Kav that you came off almost arrogant in your first couple of post. Instead of appearing to "make it your your job" to question why he has anything set to auto approve a slightly less agressive response defining what you consider "best practices" may have been the better tack.  

    His questions are legit, even more so since the TOTAL WIN7 SP1 SCREW UP by the WSUS team or MS in general. In fact don't I remember a prior update getting pushed into Critical when in fact it wasn't a year or two ago for IE7? How about WGA being set as a Security Update that was released for non-English languages Auto Approved and installed busting hundreds if not thousands of machines? Being wary of how MS/WSUS will decide to push IE9 is a good thing in my book considering the WSUS Teams history.

    Also technically speaking Update Rollups are stuff our machines should already have aren't they? If we read certain MVP Blogs we are told to select Update Rollups (sorry Susan, WSUS 3/SBS08). In fact isn't the Default setting in SBS08 set to include Update Rollups?

    "Update Rollups: Cumulative sets of hotfixes, security updates, critical updates, and updates packaged together for easy deployment. A rollup generally targets a specific area, such as security, or a specific component, such as Internet Information Services (IIS)."

    Sorry but with MS's history of WSUS screwups asking if there is a blocking tool, when we might see a package or anything else are good questions and deserve answers, not lectures. I'm all but ready to turn off WSUS approvals across the board, at least for some clients.

     

    Saturday, April 16, 2011 3:35 PM
  • I've been trying to find out when IE 9 will hit WSUS (and normal Windows Update) but haven't been able to. Anyone able to link to the appropriate information? I've tried:

    http://technet.microsoft.com/en-gb/ie/gg615599
    http://technet.microsoft.com/en-us/library/ff973978.aspx

    And various links out from these without success. I'm anxious to avoid automatically synchronising it as my environment currently auto approves update rollups and obviously don't want to do this with IE 9 until further web application testing is completed.

    Thanks,

    Stephen


    http://technet.microsoft.com/en-us/ie/gg615599

     

    Saturday, April 16, 2011 3:36 PM
  • His questions are legit, even more so since the TOTAL WIN7 SP1 SCREW UP by the WSUS team or MS in general. In fact don't I remember a prior update getting pushed into Critical when in fact it wasn't a year or two ago for IE7? How about WGA being set as a Security Update that was released for non-English languages Auto Approved and installed busting hundreds if not thousands of machines? Being wary of how MS/WSUS will decide to push IE9 is a good thing in my book considering the WSUS Teams history.
    Which is exactly why one should not have auto-approval rules configured, and exactly why I took such a strong approach to the question. What you may interpret (having only the benefit of written word which can be interpreted however you choose) as arrogance, is actually a very unequivocal awareness of reality based upon 30 years of experience in this industry.
    Also technically speaking Update Rollups are stuff our machines should already have aren't they?
    Nope. And a cursory inspection of the actual content released in that classification would make that fact self-evident.
    If we read certain MVP Blogs we are told to select Update Rollups (sorry Susan, WSUS 3/SBS08). In fact isn't the Default setting in SBS08 set to include Update Rollups?
    There's a very significant difference between synchronizing the classification (which everybody should be doing), and actually auto-approving ALL updates contained in that classification.
    Sorry but with MS's history of WSUS screwups asking if there is a blocking tool
    The blocking tool does not work in WSUS environments. It's existence is irrelevant in the scope of this conversation.
    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2011)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    My Blog: http://onsitechsolutions.spaces.live.com
    Sunday, April 17, 2011 11:07 PM
  • We approve Update Rollups automatically so we can get things like time zone definition changes as soon as possible.
    Wednesday, April 20, 2011 7:54 PM
  • You need to import updates from Windows Updates Catalog and choose Internet Explorer 9.

    Thank you

     

    Monday, April 25, 2011 5:38 PM

  • http://support.microsoft.com/kb/894199


         Tuesday, June 21, 2011


           Changes to existing non-security content:

    *Windows Internet Explorer 9 for Windows 7, Windows Server 2008 R2,
    Windows Server 2008 and Windows Vista (KB982861)*

       * Metadata changed to offer to WSUS channel.
       * Binaries have not changed.
       * This update does not need to be reinstalled.

    For more information, click the following article number to view the
    article in the Microsoft Knowledge Base:
    http://support.microsoft.com/kb/982861(http://support.microsoft.com/kb/982861)
    Wednesday, June 22, 2011 7:09 AM