none
KB2918614 Breaks MDT2012 Update 1 Task Sequence "Install Application" Items on Windows 7 deployments RRS feed

  • Question

  • Consider the following scenario:

    1. You have a WDS deployment environment for your enterprise running on Windows Server 2008 R2.
    2. You use MDT 2012 Update 01 to create a Windows 7 Task Sequence for workstation deployment. 
    3. The task sequence has an "Install Application" task to install Symantec Endpoint Protection 12.1 RU4 MP1b.
    4. You either refresh your reference build to incorporate KB2918614 or you publish the update via WSUS and use the Install Updates task in the task sequence prior to the "Install Application" task to install the hotfix. 

    In this scenario, the "Install Application" task starts but never completes. The Symantec installation executable is never called and does not show up in Task Manager. All subsequent "Install Application" tasks exhibit the same behavior. No error messages are generated. Eventually the Task Sequence itself times out and moves on to the next task. 

    If you remove update KB2918614 from your reference build or unapprove it from your WSUS server, all "Install Application" tasks in the task sequence execute correctly. 

    Has anyone else experienced a similar issues with deployments? My hunch is that the problem is not specific to the application being installed, and it may also be a problem for environments using SCCM to install Windows 7. I have not had a chance to explore this more, so I kept my scenario to the facts that I have directly observed.

    Thanks,

    Rick Reuling

    Walker IT Group, LLC

    Tuesday, August 19, 2014 10:58 PM

All replies

  • I believe we're seeing this with SCCM 2007 R2 - also with SEP, and possibly two other applications.

    I've also confirmed the behavior outside of a task squence with installing Adobe Shcokwave 12.1.3.153, which gives a key not valid for use in specific state error. Only happens with the MSI, not the EXE installer. Remove that patch, problem goes away.

    I'lll be reccomending we remove the patch from all our workstations via WSUS

    Thursday, September 4, 2014 6:45 AM
  • I would suggest opening a Microsoft Support case for this.


    Thanks,
    -Michael Niehaus
    Senior Product Marketing Manager, Windows Deployment
    http://blogs.technet.com/mniehaus
    mniehaus@microsoft.com

    Thursday, September 4, 2014 7:15 AM
  • I went back to my MDT Image "Factory" system, and verified that KB2918614 is getting installed properly. BDD.log is your friend.

    I'm having trouble tracking your problems above, you say that you have problems installing SEP, yet you also mention that all other applications have problems with installation as well? So can we assume that the problem is not with SEP? ( example, you remove SEP from your installation, and everything works fine ) OR is SEP an integral part of the installation process?

    I have been dealing this week with problems related to all the updates on Windows 7 ( I have been focused on Windows 8.x over the past two years, and just now getting back into Windows 7 ), and was quite *shocked* to see how many updates there are for Windows 7. My reference images are loading about 160. I also noticed that there were some mysterious out of Memory problems after loading 120 or so updates, so I modified the ZTIWindowsUpdate.wsf script to exit and restart after 100 updates, and updates are humming along just fine.

    Check the WindowsUPdate.log file(s) to verify the updates are getting installed correctly. Then insert a reboot between the WindowsUpdate step and the SEP installation step.

    Finally, you should be enabling logging during the SEP installation (I enable logging with most large install packages), IF the SEP install package is *not* providing you with a clear reason for failing, then open a case with Intel.


    Keith Garner - Principal Consultant [owner] - http://DeploymentLive.com

    Friday, September 5, 2014 5:35 AM
    Moderator
  • Quite the few incorrect assumptions, but thank you for your input. I disagree with your methodology and irrelevant conclusions.

    Problem is quite clearly seen under easily reproducible conditions, which according to your description was not correctly proscribed. No one ever said the patch did not install correctly.

    Whether the root cause is that mainstream third party applications are utilizing Microsoft solution accelerator proscribed methods that a privately reported vulnerability implicated as harmful; and thus the aforementioned patch changed the expected behaviour to the detriment of mainstream certified applications in an unattended environment is at fault is up for discussion. Jamal's experience implicates the overall method in not only MDT but also SCCM so there stands a reasonable chance that the problem exhibits on a further scale beyond the MDT environment.

    However, as has been documented on a real world basis in the context of actual running environments (in which many do indeed still run Windows 7, much to all our chagrin and your self-declared shock) the issue still exists, and we must decline your proposed solution as being appropriate to the described scenario. Your response clearly does not duplicate nor even attempt to recreate the problem space, If you had read clearly you would have seen we had already inserted a reboot in between the Windows Update step in the TS and the "Install Application" step. Of course there are many other potential variables, hence why one should be quite careful about declaring an explicit problem or an explicit solution. 

    I believe Mike Niehaus clearly indicated the next step, and Jamal has confirmed the immediate workaround. I will encourage my clients to raise the issue through their EA channel.

    Regards,

    Rick


    • Edited by WalkerITG Friday, September 5, 2014 7:11 AM grammatical
    Friday, September 5, 2014 7:10 AM
  • I'm experiencing the same problem as you describe when it comes to the out of memory problem. In my case it is 159 updates.

    Can you please share the modified ZTIWindowsUpdate.wsf?

    Regards,

    Fredrik

    Friday, September 19, 2014 8:43 AM
  • The fix is small.

    Change this:

    			If oInstalledUpdates.Exists(item.Identity.UpdateID) Then
    				oLogging.CreateEntry "  FOUND - " & item.Identity.UpdateID & " - " & Item.Title & kb, LogTypeInfo
    			ElseIf bInstall = TRUE then
    				oLogging.CreateEntry "INSTALL - " & item.Identity.UpdateID & " - " & Item.Title & kb, LogTypeInfo
    				updatesToDownload.Add(Item)
    			Else
    				oLogging.CreateEntry "  SKIP  - " & item.Identity.UpdateID & " - " & Item.Title & kb, LogTypeInfo
    			End if

    To This:

    			If oInstalledUpdates.Exists(item.Identity.UpdateID) Then
    				oLogging.CreateEntry "  FOUND - " & item.Identity.UpdateID & " - " & Item.Title & kb, LogTypeInfo
    			ElseIf bInstall = TRUE and updatesToDownload.count < 100 then
    				oLogging.CreateEntry "INSTALL - " & item.Identity.UpdateID & " - " & Item.Title & kb, LogTypeInfo
    				updatesToDownload.Add(Item)
    			Else
    				oLogging.CreateEntry "  SKIP  - " & item.Identity.UpdateID & " - " & Item.Title & kb, LogTypeInfo
    			End if


    Keith Garner - Principal Consultant [owner] - http://DeploymentLive.com


    Saturday, September 20, 2014 1:20 AM
    Moderator