/build/static/layout/Breadcrumb_cap_w.png

K2000 v3.7.1 - Tasks fail after using Windows 7 source with integrated updates (slipstreamed)

I've never slipstreamed Windows before so this is the first time I've gotten around to trying it. I used WSUS Offline to grab all the updates. I then used NTLite to integrate them into Windows 7 Enterprise with SP1. This also produced an ISO which tests fine and installs without any Windows Updates being needed (as of today obviously). However our post install tasks now fail. Loads of them. Anything with an exe or msi it would seem. Some of them get a green tick but when you get into the client you can see it's not actually been successful. The same task set works perfectly fine with the original Windows 7 Enterprise with SP1 or a slipstreamed source a colleague made a year ago. So there shouldn't be any issue with the tasks themselves. It's some sort of incompatibility with the slipstreamed OS of today (an update that's less than a year old perhaps???) and the task engine. It's bizarre and very disappointing.

Anyone seem this before and know how to fix it or is this a new v3.7.1 issue?

T.I.A.

3 Comments   [ + ] Show comments
  • I have seen problems when the msiexec is in use by the updates. You can only run one msi install at a time and they just get skipped - SMal.tmcc 8 years ago
  • Well the updates are integrated into the install.wim so there shouldn't be any msiexec contention. I was determined to avoid running updates one-by-one.

    I should have mentioned, I did the same thing with Windows 8.1 and it was fine. So the post install tasks aren't wrong as such. - mcnaugha 8 years ago
  • Also if I install the OS on its own via the K2000 it's fine too. - mcnaugha 8 years ago

Answers (4)

Answer Summary:
Posted by: dunnpy 8 years ago
Red Belt
1

Top Answer

Your issue seems to be.NET related, are there any updates that you've slipstreamed in for .NET?
Could it just be that you need a reboot before you run your Task List for installing apps?

See here and here for further information and possible fixes from within Windows - which won't help for your build but will give an idea of what could be causing the problem.

Hope that helps,
Dunnpy




Comments:
  • The only .NET differences would be those slipstreamed into the Windows 7 install.wim. That would be every .NET patch (pre-4.0) released in the past few years. We add .NET 4.5.2 as a post install task but this fails to run too. It works fine with an earlier build of Windows 7.

    I think it's Visual C++. I'm becoming more and more convinced this is a bug in the Task Engine where it doesn't work fully with the latest fully patched (as of today 24/7/15) Windows 7. All these MSI's run fine on the same build of Windows from within the GUI. The Task Engine seems to be the only odd-one-out here. It's unlikely the engineering team go out of their way to regularly fully test Windows 7 with integrated updates. They should though! Again this problem doesn't occur with Windows 8.1.

    I have a call logged with Dell Support. They've just asked me to build a new KBE from this new Windows 7 source. I'm thinking this could be a noob/rookie mistake if the KBE pulls resources out of the source media that may be more up-to-date than an earlier KBE. Could it be this simple? #Awkward #K2Noob - mcnaugha 8 years ago
  • I forgot there that the KBE's are built from the WAIK for Windows 7... that's probably going to mean the KBE I generate today will be identical to the one we already have... will it not? Not so noob after all??? - mcnaugha 8 years ago
    • The fresh KBE didn't work. Same errors. - mcnaugha 8 years ago
  • Reboot as the first post install task was the answer.

    You know those Windows updates that need to do stuff, like they have a script to run... well it must have been like that. I saw it even displaying the "configuring updates - don't switch off" message when I first tried the reboot. Components must have been replaced or unloaded and only a reboot would bring them back. I had thought a reboot had already occurred right at the end of the OS install but it seemed another was required. With that in place everything else pretty much returned to normal.

    So something to watch out for! - mcnaugha 8 years ago
Posted by: SMal.tmcc 8 years ago
Red Belt
0
Any further I would guessing without seeing some things on the machine itself and I do not want to give you the run around.

You may want to run the k2 advisor and see if it spots anything.

http://www.itninja.com/blog/view/k2-advisor

The Kace Techs visit this forum regularly so maybe one of them will have more incite.  Another Ninja may also have experienced this same problem and will give you an answer. 

The only other thought is the ISO did not upload properly so you want to try re-uploading again

Comments:
  • I can't get it to run. It fails saying "Line 17043: Error: subscript used on non-accessible variable" - mcnaugha 8 years ago
    • thats an autoit error. let me check with someone on that. - SMal.tmcc 8 years ago
    • is that the image or the k2 advisor? - SMal.tmcc 8 years ago
      • K2 advisor. I tried running it from both a Server 2008 R2 and a Windows 7 client. No network restrictions between these and the K2000. The off-board db access is on (and I rebooted the k2). Is it compatible with the K2 3.7.1? - mcnaugha 8 years ago
      • let me check with the author of that app - SMal.tmcc 8 years ago
Posted by: dunnpy 8 years ago
Red Belt
0
Anything in the standard Windows logs that point to where the problem might lie? The MSI failures should certainly log and if you don't see anything there for them, then it'll be the launching mechanism that is at issue.

Comments:
  • The first thing I see going wrong is something trying to install the msi for the Visual C++ 2008 Redistributable. Is this something the Task Engine does? The first thing I'm installing after the 'install drivers' task in this setup is the VMware Tools - because I'm testing with VM's. This works perfectly well with the original Win 7 SP1 source as well as a slipstreamed one from August 2014.

    The error is similar to other errors seen with the msi's that fail. Here it is:

    Product: Microsoft Visual C++ 2008 Redistributable - x86 9.0.30729.4148 -- Error 1935.An error occurred during the installation of assembly 'Microsoft.VC90.ATL,version="9.0.30729.4148",publicKeyToken="1fc8b3b9a1e18e3b",processorArchitecture="x86",type="win32"'. Please refer to Help and Support for more information. HRESULT: 0x80070BC9. assembly interface: IAssemblyCacheItem, function: Commit, component: {A75F2217-AD54-3EA6-AE14-F255F8660531}

    This is the error recorded when the next msi fails and it's one of the iTunes install components:

    Product: Apple Application Support (32-bit) -- Error 1935. An error occurred during the installation of assembly 'Microsoft.VC80.CRT,type="win32",version="8.0.50727.6195",publicKeyToken="1fc8b3b9a1e18e3b",processorArchitecture="x86"'. Please refer to Help and Support for more information. HRESULT: 0x80070BC9. assembly interface: IAssemblyCacheItem, function: Commit, component: {98CB24AD-52FB-DB5F-A01F-C8B3B9A1E18E}

    I'm seeming a common theme with the references to VC... which I'm assuming is Visual C++.

    There are repeated entries saying there is a problem with the .NET Optimisation Service not matching the repository.

    Earlier there was an WMI error:

    Event filter with query "SELECT * FROM __InstanceModificationEvent WITHIN 60 WHERE TargetInstance ISA "Win32_Processor" AND TargetInstance.LoadPercentage > 99" could not be reactivated in namespace "//./root/CIMV2" because of error 0x80041003. Events cannot be delivered through this filter until the problem is corrected.

    I don't know if this is random or if the Task Engine triggered this.

    The Apple Application Support 64-bit goes on to fail:

    Product: Apple Application Support (64-bit) -- Error 1935. An error occurred during the installation of assembly 'Microsoft.VC80.CRT,type="win32",version="8.0.50727.6195",publicKeyToken="1fc8b3b9a1e18e3b",processorArchitecture="amd64"'. Please refer to Help and Support for more information. HRESULT: 0x80070BC9. assembly interface: IAssemblyCacheItem, function: Commit, component: {844EFBA7-1C24-93B2-A01F-C8B3B9A1E18E}

    Then Apple Mobile Device Support fails with:

    Product: Apple Mobile Device Support -- Error 1920. Service 'Apple Mobile Device Service' (Apple Mobile Device Service) failed to start. Verify that you have sufficient privileges to start system services.

    Ironically the iTunes6464.msi proceeds successfully but of course can't work without the previous msi's being there.

    The next error is when Sophos Anti-Virus setup runs:

    Product: Sophos Anti-Virus -- Error 1935.An error occurred during the installation of assembly 'Microsoft.VC90.ATL,version="9.0.30729.4148",publicKeyToken="1fc8b3b9a1e18e3b",processorArchitecture="x86",type="win32"'. Please refer to Help and Support for more information. HRESULT: 0x80070BC9. assembly interface: IAssemblyCacheItem, function: Commit, component: {A75F2217-AD54-3EA6-AE14-F255F8660531}

    Again a Visual C++ issue it would seem. Slightly newer version this time.

    Note that all of these msi's worked prior to this fully patched Windows 7 within our set of post install tasks. Also note that these msi's work perfectly when run manually on the incomplete but accessible target workstation. So it seems to me to be an issue with the Task Engine from 3.7.1 being incompatible with the state of Windows as fully patched today.

    Again no problem like this with Windows 8.1 slipstreamed. Do they use a different build of the Task Engine with Windows 8.1??? - mcnaugha 8 years ago
Posted by: SMal.tmcc 8 years ago
Red Belt
0

Comments:
  • I might try rebuilding the slipstreamed Windows 7 and see if it works better a second time; if it is a corrupt registry as per your link. It's bizarre though that when I can get into the GUI, I can run any of these MSI/EXE's there and they are fine. That still makes me suspect the Task Engine. - mcnaugha 8 years ago
  • The new slipstreamed Windows 7 was even messier but I think we have a winner in terms of what was needed to fix this... just performing one final (I hope final) deployment to confirm that the post install tasks now all run without intervention. I'll be back to mark the best answer. - mcnaugha 8 years ago
 
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ