K2000 3.6 - Slow Imaging After Upgrade
Has anyone else experienced a longer amount of time when deploying images after upgrading to 3.6 on their K2000. Our image, which is a K-Image file at approximately 12.4 GB, seems to be taking a much longer time to deploy after the upgrade. I've stripped away all of our own PO tasks (leaving only the K2000 default tasks), and have left our Pre-installation tasks (partition, format, mbr) in place.
On 3.5; with normal network related constraints, it would take approximately 40-50 minutes to deploy the image to one of our systems.
On 3.6; (tested on the weekend where network utilization was at its lowest), it took approximately 2h 20m to deploy the same image down to a system.
During the deployment, it takes this amount of time at Step 4 - Apply Image. I don't believe it to be any of the Dell PO tasks as it doesn't even appear to get that far until the deployment finally completes.
Am wondering where I can begin to look at why there is such a significant delay in deployment now that we are on 3.6.
Thank you.
-
Since the latest upgrade 3.6.98680 we have seen it too. I'm trying to remake some k-image ( xp, win7 and win 8 ) and test with winpe 5 + ADK. Maybe some drivers are faulty... - fantomasss 10 years ago
-
I opened a ticket with Dell today on this issue so if I get something useful, I will comment here as well. He mentioned that the scenario usually happens with .wim files; not k-image files. - dtobias_keenan 10 years ago
-
I have seen this as well. Deployment times up to three times longer on 3.6. Nothing about our deployment process has changed other than the upgrade. Just about ready to open a ticket... - gochjj 10 years ago
-
Thanks for the confirmation. They just responded to my ticket so I'm working with them in the troubleshooting process. I'll continue to update this thread as we progress our troubleshooting. - dtobias_keenan 10 years ago
-
did they ever get back to you? I have the same issue with 3.6. Thank you - joeysparrow 10 years ago
-
Any update on this ? I'm using wim's and its slower since upgrade to 3.6 ... - pentopg 10 years ago
-
Hello All ! Looks like theres a few of us with the same issue now, was really hoping someone would have a fix for this...I am supposed to send a Log file to the Level 2 Kace rep when he contacts me, will keep you guys posted if anything gets resolved.. - Seb777 10 years ago
-
Thanks, Seb. Didn't mean to give off the vibe that my solution was the end-all. In my case, rebuilding as .wim just happened to correct my slowness issue. It'll be interesting to continue monitoring and see what your support individual has to say. - dtobias_keenan 10 years ago
Answers (2)
So it looks like rebuilding my image as a .wim file rather than the default k-image format was enough to correct my issues. Doing this brought down my deployment time from 2.5 hours to 50 minutes. Since I only have one image at this time, it's the easier and logical choice for me to just go this route.
KACE support was veering me towards this route anyways as they did not seem to want to troubleshoot on how/why the 3.6 upgrade changed my original K-Image file. For others experiencing this, it may simply be an easier fix if you have one or two images, to just rebuild and recapture them as .wim files.
Thanks.
Comments:
-
Wim files are a much better way to go. They a like a zip file so they stream much faster then trying to use the kimage file copy process. With kimages The image is not a image file but a dataset with a list of files. The k2000 needs to look at the files in its library and collect them for an image, since you can have many files with the same name it uses other logic to know if it is the correct file, which requires SQL processing and that will slow you down.
I use wims and store them externally to the kbox, My admin image is about 16gig compressed 40gig on the HDD and I can deploy it to a single machine in 35 minutes.
http://www.itninja.com/blog/view/wim-storage-freeing-up-space-on-your-k2000-if-you-are-using-wims-k2000-version-3-6 - SMal.tmcc 10 years ago
All-
Let me offer an update on this matter. As of today, it's still an open support ticket with Kace support and unfortunately we have not made a lot of progress. Please note, in our environment, we only use one image for our systems. We're not a tremendously large shop where multiple different images might be used. Initially, our support technician had me upload the contents of the Panther directory on a system that had experienced a long deployment time post-3.6 upgrade. In the Panther log files, they denoted a series of errors
2013-03-20 07:54:33, Error SYSPRP SPPNP: Error 0x2 setting
SDDL on driver file C:\Windows\system32\igfxsrvc.exe!
2013-03-20 07:54:33, Error SYSPRP SPPNP: Error 0x2 setting
SDDL on driver file C:\Windows\system32\igfxtray.exe!
2013-03-20 07:54:33, Error SYSPRP SPPNP: Error 0x2 setting
SDDL on driver file C:\Windows\system32\igdbcl64.dll!
2013-03-20 07:54:33, Error SYSPRP SPPNP: Error 0x2 setting
SDDL on driver file C:\Windows\system32\igdrcl64.dll!
I couldn't be entirely certain whether these errors were still there in 3.5, or if the 3.6 upgrade is now somehow triggering them. Regardless, per the suggestion of Kace support, I created a very basic K-Image file, went through sysprep and captured it back to the K2000. When deploying, the same 2.5 to 3 hour deployment time was present. Kace support doesn't seem very eager to troubleshoot from the upgrade causing the issue perspective. The next step they want me to do is to recapture as a .wim file (which I'm going to do this upcoming weekend). Since we only have one image and we're not really reliant on the data deduplication technology that the K-Image format offers; if this works to correct my deployment time issues, I'll probably consider that a solution in our case (although for organizations that have multiple images, it probably won't suffice).
One interesting note though....if I capture my K-Image without being sysprepped; I can turnaround and deploy it down to a system in about 40 minutes. If the captured image is sysprepped, then I begin to see the long deployment times. I'm not entirely sure at this point why that is though. I will continue to keep this thread updated after this weekend when I have a chance to see how the .wim file reacts.
Thanks