Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Question
Thursday, May 10, 2012 8:30 PM | 1 vote
Hello, we have recently finished migrating to Configuration Manager 2012. We also just migrated all of our applications from the Package/Program model to the new Applications model. Everything appears to be working great except one exception. With using the "Install Application" step in a OSD task sequence, the applications take a really long time to install (they do succeed eventually). For example, I have about 8 really light applications that I am installing here, they each should take about 30 seconds to install; however, when deploying from OSD, they are taking close to 4-5 minutes to install each. My old package/programs took about 4-5 minutes to apply all 8 applications, the new applications are taking around 25 minutes. When I deploy these same applications to regular clients (not during OSD), they work great and apply very fast (30 seconds max for each one). Any thoughts on why the huge time delay in OSD, in really adds up when have several applications? Thanks!
All replies (68)
Thursday, December 13, 2012 11:50 PM ✅Answered
Actually, Jason, not including software updates in the task sequence won't make any difference. The policies that are received by the client and subsequently compiled before each app installation include any CI-based deployments targeted at the client, even if they aren't referenced in the task sequence. So, if you are deploying a task sequence to an existing client and that client has a large number of updates and/or applications deployed to it, all of those policies will be compiled during the task sequence. If you are dealing with a brand new machine with no existing client, then you're still dealing with anything deployed to All Unknown Systems or All Systems.
Yannara, unfortunately I can't explain why you might be seeing an issue with x64 and not with x86. Perhaps you have different collections for each architecture and have different deployments targeted to each?
Friday, January 4, 2013 4:38 PM ✅Answered
I have run a few tests with the RTM of SP1 and this issue has indeed been fixed.
Thursday, May 24, 2012 11:36 PM
Can you please post the smsts.log file and execmgr.log file? There might be some hint somewhere as to which process takes a long time to complete.
Tuesday, May 29, 2012 7:34 PM
Kerwin, thanks for the reply. Sorry for the delay with info, I was out of the office for a couple of days. It is hard to interpret the SMSTS logs as there isn't a lot of unique data in them, but they simply alot of same line of output hundreds of times and the log quickly rolls over (both times). Below are the repeated lines in the SMSTS.log file (the first line, each time is repeated, has a slightly different ScopeID, the second line comes later and is the same thing everytime):
<![LOG[ModelName = ScopeId_40126423-B61F-4C90-8033-B1F58FEF2DC6/Application_491cef80-2638-4011-9bf9-292dd4719121]LOG]!><time="10:45:24.560+300" date="05-29-2012" component="InstallApplication" context="" type="1" thread="3612" file="utils.cpp:2722">
<![LOG[Converting input value from 19 to 3]LOG]!><time="10:45:32.453+300" date="05-29-2012" component="InstallApplication" context="" type="0" thread="3612" file="wmiobject.cpp:665">
Also, I can send you the entire log if you have someone that I can post/send it? Also, there doesn't appear to really be anything in the ExecMgr log outside of the registration of the client (from install).
Any thoughts? Thanks!
Tuesday, May 29, 2012 11:14 PM
I think you have a lot of update policies.
What is happening is that all targeted policies are compiled just before an app is installed. That takes a while. Then, the deletion of the policies at the end of the task sequence takes even longer.
I suggest that you move to dynamic updates.
Wednesday, May 30, 2012 1:11 AM
Kerwin, thanks for the info! Can you be more specific about the update policies? Are you referring to actual software updates, or client policies, or ...? And what do you mean by dynamic updates, I don't remember seeing an option about that anywhere in the console? Thanks!!
Wednesday, June 6, 2012 10:45 AM
Hi,
I am also seeing same problem with my environment.
I have 17 applications that are installing through Install application -step in the task sequence.
In each application installation case there is about 4 minutes delay before installation starts.
Kerwin, I would also like to know are you referring to software updates when you are saying that policies are compiled just before an app is installed?
Br Jussi
Thursday, June 7, 2012 6:20 AM
Hi,
You were right Kerwin.
Problem really was in the patch deployment side (all the patch deployment policies are evaluated before starting application installation).
When there are no patches deployed to workstations I am installing then the application installation time is really fast.
Thanks for the tip Kerwin.
Br Jussi
Wednesday, June 13, 2012 4:02 PM
Kerwin, why does Software Update advertisement affect Applications? This seems like an inefficient dependency? It is required for us to patch our systems using the Install Software Updates step after installing all of our Applications in a task sequence. Are you saying that it is impossible to use both Install Applications step together with Install Software Updates step in the same task sequence without major performance problems? Or is there another workaround? Please advise, thx!
Thursday, June 14, 2012 2:28 AM
If you have a lot of updates, the compilation takes a long time.
The same thing can happen if you have a lot of apps. However, it is not very easy to create a lot of apps, whereas it is very easy to create a lot of updates.
I suggest you use offline servicing instead.
Friday, June 15, 2012 6:25 PM
Are policy complilations based on Advertisements or just on how many updates a machine is pending. Why are apps and updates dependent on each other? Seem very inefficient? Any plans to fix this in near future? (ie. sp1?)
Friday, June 15, 2012 8:36 PM
Apps and updates are not dependent on each other.
What I am saying is that one update is a configuration item that needs to be compiled. If you have many of these, the compilation can be slow.
Similarly, each app is a configuration item. If you have many apps, the compilation can also be slow.
I'm just warning you that if you also have a lot of apps, you will also experience the same slowness.
Friday, June 15, 2012 8:43 PM
That makes sense. How come they are re-compiled after each app and not just once at the start of TS? Is there anyway to change this behavior? Having a 5 minute delay once during the first install wouldn't be that big of a deal if it didn't happen again for every subsequent app and update installs.
Thursday, June 21, 2012 2:46 AM
I thought I would just follow up as well. What Kerwin says seems to be true. I had updates being applied to the computers and I saw the issue. It was only a few hundred updates in my case just windows XP security and critical updates so nothing insane like thousands of updates. At first I turned off the software updates via a policy and I confirmed via WMI that no update information was downloaded but I still saw the long delay. I then removed the update group deployments and sure enough the installs happened much quicker as well as the system using a lot less memory.
For now I will just not use CM for updates though it seems like a shame. I would like to know if this is common for other using Updates+TS+Applications.
Monday, July 9, 2012 6:55 AM
I am seeing the same behaviour in multiple CM12 environments. I don't understand why a full compilation of content IDs is performed before each application is installed - why not just do it once? Offline Servicing is not a complete solution as it does not allow for all types of Microsoft Updates (such as Office Updates) to be injected into the WIM.
Is this going to change in SP1?
Wednesday, July 11, 2012 2:40 AM | 1 vote
To get around this behaviour, we are now using packages/programs for OSD only and using the Application Model for Tier 2 applications. We have also configured all our packages to "Copy the content in this package to a package share on the distribution point” so that the Deployment can now be configured to "Access content directly from a distribution point when needed by the running task sequence"
This has reduced deployment time significantly and unless this issue is changed in SP1, we will continue using packages/programs in OSD.
Friday, July 20, 2012 2:40 PM
I agree with slewis above. Except that I am finding it really difficult to maintain in that model. This is because I am having issues with the content distribution to the regular package share. When I add a step to a task sequence and then select the Distribute Content button on the ribbon, I am unable to select the DP again and so I can't get the task sequence to update those files, so the new package does not appear in the distribution share and task sequence fails.
I hate to have to redo this every time.
Could someone from Microsoft please advise us on this issue? Is a fix for this coming? I have the sense they figured that we just use the nifty Content Library but the performance for OSD is just not acceptable.
Friday, July 20, 2012 5:55 PM
I have been testing OSD on and off for the past 2 weeks. I now have a Task Sequence that builds a custom image and without updates it reliably takes 2 hours to finish. This includes over 50 application model applications as well as a few packages but mostly applications. Enabling the deployment of updates took the time from 2 hours to 14 hours and I have not even approved all the possible updates yet! For the time being I plan on making that task sequence a build and capture and just deploy the generated image to the end user. I was probably going to do this any way but even still a build and capture process that takes that long is pretty scary.
Saturday, July 21, 2012 6:40 PM
Having exactly the same problem & currently finding it impossible to even successfully run a Build & Capture Task Sequence. The Build & Capture Sequences contain around 65-70 Applications (slight variation for 32-Bit & 64-Bit, some very small, configuration scripts etc) & a couple of hundred updates to patch Windows 7 & Office 2010 to current levels, it gets progressively slower & slower to the point where even Applications with very small content are taking forever to download & execute, this is even before the Software Update step which is set to run after application installation. The sequence which I would expect to take 3-4 hours to run & capture takes around 13 hours then fails at the "Prepare Configuration Manager Client" stage with an error in the smsts.log "Unable to delete all client policies". Even disabling the Software Updates step doesn't resolve this problem.
I have done a basic Build & Capture with 3 application & no updates to prove functionality, and this works fine & is reasonably fast but is not much use for our production environment where these applications must be installed on all clients & they must be fully patched for compliance, the simplest method therefore being to include these in the base WIM but this seems to be impossible at present with 2012.
I would also be very interested to know why a full compilation of all Content IDs is done before each Application as this seems to be a very inefficient method, I can see why dependancies for each Application need to be checked by why all, including Software Updates ? Why can't the Content ID for each dependancy in the Task Sequence be enumerated once, this is done at the start of the task sequence anyway to check all Content is available ?
I assume switching the apps used in OSD from Applications to Packages in itself will not fix this issue as it still uses the Content Library ? This seems to be a very basic & fundamental problem with ConfigMgr 2012 which Microsoft need to address urgently & i'm amazed wasn't picked up during Beta testing, with the number of OSD related issues i've had with 2012 I am actually considering abandoning the migration from 2007 to 2012 as it doesn't seem fit for purpose.
Tuesday, July 31, 2012 3:08 PM
Looks like I have the same issue.
I posted a bug if anyone wants to contribute to it and vote it up.
Chris Summers
Tuesday, July 31, 2012 3:10 PM
Voted, thx for creating the connect post.
Wednesday, August 1, 2012 3:36 PM
Looks like MS still wants a support case open :-(. I still have my 2 support cases from my Technet subscription so I did open one. I will post back here when I find something out.
Thursday, August 2, 2012 5:04 AM
I have been looking into this. I can see what is causing the delay with the Task Sequence, but I don't know why.
The DataTransferService.log file shows jobs are being submitted to BITS for downloading, these jobs are only kb in size, but it' taking a long time for the job to be processed.
<![LOG[UpdateURLWithTransportSettings(): OLD URL - <time="14:06:06.919-600">http://the-clients-sccm.server.fqdn:80/SMS_MP]LOG]!><time="14:06:06.919-600" date="08-02-2012" component="DataTransferService" context="" type="1" thread="2040" file="ccmutillib.cpp:3095">
<![LOG[Added (source=.sms_dcm?Id&DocumentId=ScopeId_1BE05238-A06B-4C18-B991-0B4A5F624BDD/RequiredApplication_b421899d-4f9a-4186-b3a6-f09282f8a43f/6/MANIFEST&Hash=EE8BDDDE1305D2BCB6E7BF7E9D4483A0906C1728EBD867CA35BE8F53406A6822&Compression=zlib,dest={311A93D6-8ADF-4C29-A889-541C3F8ADD7A}_1.zip) pair from manifest.]LOG]!><time="14:06:06.919-600" date="08-02-2012" component="DataTransferService" context="" type="1" thread="2040" file="util.cpp:2449">
<![LOG[Added (source=.sms_dcm?Id&DocumentId=ScopeId_1BE05238-A06B-4C18-B991-0B4A5F624BDD/RequiredApplication_b421899d-4f9a-4186-b3a6-f09282f8a43f/6/PROPERTIES&Hash=1C08911E61C97B326F385583D0C1F2A317CD083D665A2392E1BEF90A960F14EF&Compression=zlib,dest={311A93D6-8ADF-4C29-A889-541C3F8ADD7A}_2.zip) pair from manifest.]LOG]!><time="14:06:06.919-600" date="08-02-2012" component="DataTransferService" context="" type="1" thread="2040" file="util.cpp:2449">
<![LOG[DTSJob {08D621F8-B142-4BB8-8C3A-FA78EE45057A} created to download from 'http://the-clients-sccm.server.fqdn:80/SMS_MP' to 'C:\Windows\CCM\CIDownloader\Staging'.]LOG]!><time="14:06:06.935-600" date="08-02-2012" component="DataTransferService" context="" type="1" thread="2040" file="datatransferservice.cpp:186">
<![LOG[DTSJob {08D621F8-B142-4BB8-8C3A-FA78EE45057A} in state 'PendingDownload'.]LOG]!><time="14:06:06.935-600" date="08-02-2012" component="DataTransferService" context="" type="1" thread="3352" file="dtsjob.h:157">
<![LOG[DTSFlag is 0x00001c8a]LOG]!><time="14:06:07.028-600" date="08-02-2012" component="DataTransferService" context="" type="1" thread="3352" file="bitshelper.cpp:347">
<![LOG[Exclude file list: ]LOG]!><time="14:06:07.028-600" date="08-02-2012" component="DataTransferService" context="" type="1" thread="3352" file="bitshelper.cpp:354">
<![LOG[Using branch cache option]LOG]!><time="14:06:07.044-600" date="08-02-2012" component="DataTransferService" context="" type="1" thread="3352" file="bitshelper.cpp:374">
<![LOG[DTSJob {08D621F8-B142-4BB8-8C3A-FA78EE45057A} in state 'DownloadingData'.]LOG]!><time="14:06:07.356-600" date="08-02-2012" component="DataTransferService" context="" type="1" thread="3352" file="dtsjob.h:157">
When I look at the BITS jobs, the job handling the download sits in 'unknown' for a long time, it then moves to 'queued' where it stays for aaaages.
{63389FA0-302D-413A-91EC-90BB8BB2ED51} 'CcmSetup BITS Version Check' SUSPENDED 0 / 0 0 / 0
{F82F96E7-EC96-4A37-8488-653137AC1D70} 'SMS Client Setup Test Job' SUSPENDED 0 / 0 0 / 0
{CDC4B637-A11A-4EA7-B6D8-45347DBF243C} 'CcmSetup BITS Version Check' SUSPENDED 0 / 0 0 / 0
{FADEBB2E-2552-4D41-B2D1-FA12EAEDF519} 'SMS Client Setup Test Job' SUSPENDED 0 / 0 0 / 0
{70E1924B-2231-42DF-93D2-C29C45433A1B} 'CCMDTS Job' QUEUED 0 / 2 0 / UNKNOWN
{71C6C1CE-CC7A-43F4-99BA-511A0E45FB87} 'CCMDTS Job' QUEUED 0 / 38 0 / UNKNOWN
{9D15B619-4E1D-4E7A-9DE5-F191EBB6398A} 'CCMDTS Job' QUEUED 0 / 2 0 / UNKNOWN
{D4F2427D-B7A4-49A7-A97C-8C1DA47D4FC1} 'CCMDTS Job' QUEUED 0 / 2 0 / UNKNOWN
{DF77A20B-02DE-41BB-9CB8-9273F5379E81} 'CCMDTS Job' QUEUED 0 / 2 0 / UNKNOWN
{A5D04C83-9FE3-4D66-8E1C-DFF0846D4889} 'CCMDTS Job' QUEUED 0 / 2 0 / UNKNOWN
{66020C9A-3B53-41B5-A767-E3B99CC68269} 'CCMDTS Job' QUEUED 0 / 192 0 / UNKNOWN
Listed 11 job(s).
Most of these jobs are orphaned, some of them are from the BUILD environment where the Image Capture took place (ConfigMgr doesn't appear to be cleaning up the BITS jobs...)
This is one of the actual job file lists
GUID: {A5D04C83-9FE3-4D66-8E1C-DFF0846D4889} DISPLAY: 'CCMDTS Job'
TYPE: DOWNLOAD STATE: QUEUED OWNER: NT AUTHORITY\SYSTEM
PRIORITY: FOREGROUND FILES: 0 / 2 BYTES: 0 / UNKNOWN
CREATION TIME: 2/08/2012 2:06:06 PM MODIFICATION TIME: 2/08/2012 2:06:07 PM
COMPLETION TIME: UNKNOWN ACL FLAGS:
NOTIFY INTERFACE: REGISTERED NOTIFICATION FLAGS: 11
RETRY DELAY: 60 NO PROGRESS TIMEOUT: 28800 ERROR COUNT: 0
PROXY USAGE: NO_PROXY PROXY LIST: NULL PROXY BYPASS LIST: NULL
DESCRIPTION:
JOB FILES:
0 / UNKNOWN WORKING http://the-clients-sccm.server.fqdn:80/SMS_MP/.sms_dcm?Id&DocumentId=ScopeId_1BE05238-A06B-4C18-B991-0B4A5F624BDD/RequiredApplication_b421899d-4f9a-4186-b3a6-f09282f8a43f/6/MANIFEST&Hash=EE8BDDDE1305D2BCB6E7BF7E9D4483A0906C1728EBD867CA35BE8F53406A6822&Compression=zlib -> C:\Windows\CCM\CIDownloader\Staging\311A93D6-8ADF-4C29-A889-541C3F8ADD7A}_1.zip
0 / UNKNOWN WORKING http://the-clients-sccm.server.fqdn:80/SMS_MP/.sms_dcm?Id&DocumentId=ScopeId_1BE05238-A06B-4C18-B991-0B4A5F624BDD/RequiredApplication_b421899d-4f9a-4186-b3a6-f09282f8a43f/6/PROPERTIES&Hash=1C08911E61C97B326F385583D0C1F2A317CD083D665A2392E1BEF90A960F14EF&Compression=zlib -> C:\Windows\CCM\CIDownloader\Staging\311A93D6-8ADF-4C29-A889-541C3F8ADD7A}_2.zip
NOTIFICATION COMMAND LINE: none
owner MIC integrity level: SYSTEM
owner elevated ? true
Peercaching flags
Enable download from peers :true
Enable serving to peers :true
CUSTOM HEADERS: NULL
Once the BITS job has completed, the application goes on to install like normal (until the next application, then the whole process starts again).
I can't help but wonder if this is due to peer caching.
Ben
Thursday, August 2, 2012 5:23 AM
I can see in the IIS logs for the Management Point, it appears to be responding to the request from BITS OK...
2012-08-02 04:48:14 10.127.128.129 GET /SMS_MP/.sms_dcm Id&DocumentId=ScopeId_1BE05238-A06B-4C18-B991-0B4A5F624BDD/RequiredApplication_b421899d-4f9a-4186-b3a6-f09282f8a43f/6/MANIFEST&Hash=EE8BDDDE1305D2BCB6E7BF7E9D4483A0906C1728EBD867CA35BE8F53406A6822&Compression=zlib 80 - 10.127.128.129 Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+6.1;+WOW64;+Trident/5.0;+SLCC2;+.NET+CLR+2.0.50727;+.NET+CLR+3.5.30729;+.NET+CLR+3.0.30729;+.NET4.0C;+.NET4.0E) 200 0 0 11
Friday, August 3, 2012 12:29 AM
We are seeing the same in our environment. Really hope to see some traction on getting this resolved.
Friday, August 17, 2012 6:37 AM
Yep, same here.
Friday, August 31, 2012 8:44 PM
I have run into this issue as well using SCCM 2007. From further investigating and troubelshooting, I noticed that this behavior occurs when the package's Distribution Settings > Allow this package to be transferred via multicast (WinPE only) is enabled. When I disable this feature, the packages for my task sequence download/cache and execute immediately with no 2-4 minute delay.
If I turn off this multicast feature for each of my packages for my OSD, what will occur if I have multiple PCs receiving my OSD task sequence? Will it not be possible?
Saturday, September 1, 2012 2:38 AM
I did open a case with MS and I am working with them on this but I thought I would post some of my results. I made a very simple software only task sequence which installs 7zip 8 times. Really it never has to install I am just testing the policy evaluation speed in this case. My 3 time trials without updates were 2.5, 2.2 and 2 minutes. I rebooted between tests and let the computer come to a rest before starting the task sequence. After that I deployed 4 update groups all for Windows XP updates which totaled to 334 updates. After that it took 30 and 29 minutes for the same task sequence! This was actually faster then I saw before but still pretty bad especially given the limited number of updates.
Tuesday, September 11, 2012 9:03 PM
Just finished up with the support case but because the task sequence does complete and everything works there is nothing they can do at the professional support level. I was told if I can open a premiere support case that they will be able to investigate the issue further however I don't have access to that level of support. They did confirm that that it was DCM compiling policies at each application install that was causing the delay but there were not workarounds.
So if anyone out there has any premiere support cases you may want to give this case a shot.
Wednesday, October 10, 2012 2:11 PM
Having the exact same issue during Build & Capture for Win7.
Each application install starts about 6 minutes after the last one has completed, very very frustrating!
Is there a way to bypass DCM compiling policies somehow, if that's the case why it's taking so damn long... ?
Wednesday, October 10, 2012 2:38 PM
Has anyone tried this with the SP1 Beta build? We believe we have addressed the policy compilation issue, so would be interested in hearing the results of your testing.
Thursday, October 11, 2012 10:48 AM
Having exactly the same problem & currently finding it impossible to even successfully run a Build & Capture Task Sequence. The Build & Capture Sequences contain around 65-70 Applications (slight variation for 32-Bit & 64-Bit, some very small, configuration scripts etc) & a couple of hundred updates to patch Windows 7 & Office 2010 to current levels, it gets progressively slower & slower to the point where even Applications with very small content are taking forever to download & execute, this is even before the Software Update step which is set to run after application installation. The sequence which I would expect to take 3-4 hours to run & capture takes around 13 hours then fails at the "Prepare Configuration Manager Client" stage with an error in the smsts.log "Unable to delete all client policies". Even disabling the Software Updates step doesn't resolve this problem.
I don´t see any point of building .wim with software included. I always use bare OS .wim, but sure it would be nice to have all critical and security updates included in .wim.
About the original question - just to make sure, when you guys are talking about slow application installation turing TS run, do you really measure a single step duration, not entire TS process? Just thinking, if you are running software updates steps during TS, perhaps you should test the TS run without any software updates. I have entire TS which has several applications and over 100 software updates. Only the software update steps takes 1,5 hours which is the longest single step.
Thursday, October 11, 2012 11:18 AM
The reason to include all the software in a WIM is for speed and reliability. I can take a task sequence that takes a few hours to run turn it into a WIM and deploy it in under an hour. You don't have to do it and I don't do it for all my images but for my larger ones and especially with this problem making a fat image definitely helps.
In regards to measuring step duration I have not measured the exact step duration for application installs but I can replicate the problem by running a TS which only contains Application installs. See my post on September 1st where I reproduce this problem without the software update step and only deploying updates to a collection. I discovered this problem before I even added the software update steps to my task sequence. Just the updates being set for deployment to the machine is enough to slow the whole task sequence.
Monday, October 15, 2012 3:43 PM
Just wondering are you guys seeing this happening when the distribution point has "Allow clients to connect anonymously" checkbox unchecked?
I haven't got the time to test it out with the checkmark yet.
Wednesday, October 17, 2012 12:00 PM
Just wondering are you guys seeing this happening when the distribution point has "Allow clients to connect anonymously" checkbox unchecked?
I haven't got the time to test it out with the checkmark yet.
I just tested this, doesn't seem to make any difference on the slowness.
Has anyone tested this with SP1 yet? And does MS have anything new to say about this?
Wednesday, October 17, 2012 1:09 PM
And does MS have anything new to say about this?
Do you mean newer than what I posted a week ago when I asked if anyone had tried this with SP1 Beta? I still haven't seen any response to that question.
Wednesday, October 17, 2012 4:07 PM
And does MS have anything new to say about this?
Do you mean newer than what I posted a week ago when I asked if anyone had tried this with SP1 Beta? I still haven't seen any response to that question.
That's why I was asking... haven't got the time to test it with SP1 myself.
Tuesday, October 23, 2012 11:57 AM
I'm facing exactly the same Issue and will test the SP1 Beta with the same amount of Updates and Applications.
Will inform you guys the next days.
Daniel Meili
Tuesday, October 30, 2012 2:43 PM
I'm getting the same issue having tried various combinations of TS using MDT and without. Sometimes things like Lync will install in a few seconds, but Flash, Office, Reader and all those things that are fairly standard are literally taking hours.
I read this post: http://myitforum.com/myitforumwp/2012/07/31/installing-applications-via-the-configuration-manager-2012-task-sequence-takes-a-long-time/
If someone feels the need to try that one out (I'm not going to get time today, halfway through a build!)
MCP, MCDST, MCTS x 6, MCITP x 3
Please don't forget to mark this post as an answer if it is the solution to your problem!
If you like trance music, please subscribe to my podcast Trancendance Podcast
Follow me on Twitter
Tuesday, October 30, 2012 3:21 PM
I checked the post and unfortunately it does not apply to us. I am already in AHCI mode and I inject the correct AHCI driver during imaging. The problem I and what I assume many people here are seeing is the policy compiling and evaluation takes time. The actual install happens fast and is even slow if nothing gets install (It determines the app is already installed).
Wednesday, November 7, 2012 12:11 PM
I've been having a play and I seem to have gotten around the problem using command line switches.
For instance, with office, if I create a settings file and use the switch /adminfile <path to msp> office takes just a few minutes to install.
Unfortunately some things require creating cmd files instead. I'm going to make some posts about the ones I've found that work on my website a bit later.
MCP, MCDST, MCTS x 6, MCITP x 3
Please don't forget to mark this post as an answer if it is the solution to your problem!
If you like trance music, please subscribe to my podcast Trancendance Podcast
Follow me on Twitter
Wednesday, November 7, 2012 3:51 PM
Interesting stuff Brian. I'm very interested in who you manage to install Office in a few minutes since my install (with msp file) easily takes 15 minutes.
Can you give some more details?
Thanks.
Wednesday, November 7, 2012 3:55 PM
I'll post the config I used, but I didn't time it and if I'm busy, 15 mins could seem like a few minutes to me, although I think it was less than that, and it was over a 1gig link.
Its unlikely to be today but I'll post a link to the config used when I've put it up.
MCP, MCDST, MCTS x 6, MCITP x 3
Please don't forget to mark this post as an answer if it is the solution to your problem!
If you like trance music, please subscribe to my podcast Trancendance Podcast
Follow me on Twitter
Thursday, November 8, 2012 4:47 PM
I'm also interested hearing about this...
I've got different kind of apps being installed, here's list of install commandlines
- xcopy
- office with the msp
- msi (multiple) with and without .mst files
- scripts (.vbs)
Thursday, November 8, 2012 4:55 PM
Is there anyone that has tried the SP1 Beta? Would love to get some feedback to see if the fixes we made have helped at all.
Friday, November 9, 2012 10:25 AM
Once I've had a chance to document them for work I'll turn them into something more web friendly. That no one appears to have created a "this is what has worked for me" repository is doing my head in, so I have every intention of creating one. Hopefully by the end of next week i'll have started it and I'd value any further input or suggestions.
MCP, MCDST, MCTS x 6, MCITP x 3
Please don't forget to mark this post as an answer if it is the solution to your problem!
If you like trance music, please subscribe to my podcast Trancendance Podcast
Follow me on Twitter
Friday, November 9, 2012 10:29 AM
Unfortunately not. As several admin tools don't work on Windows 8 properly without hefty server patching or workarounds (hyper-v and exchange are two that immediately come to mind), Windows 8 is not getting deployed here any time soon. Which is a shame as we were very excited about it.
MCP, MCDST, MCTS x 6, MCITP x 3
Please don't forget to mark this post as an answer if it is the solution to your problem!
If you like trance music, please subscribe to my podcast Trancendance Podcast
Follow me on Twitter
Friday, November 9, 2012 3:29 PM
Unfortunately not. As several admin tools don't work on Windows 8 properly without hefty server patching or workarounds (hyper-v and exchange are two that immediately come to mind), Windows 8 is not getting deployed here any time soon. Which is a shame as we were very excited about it.
If this is in reference to testing on ConfigMgr 2012 SP1 Beta, you don't need to deploy Windows 8 to test it. You can use it to deploy Windows XP, Windows Vista, and Windows 7, too. Whatever task sequence you're using on ConfigMgr 2012, you should be able to take that same task sequence and run it on ConfigMgr 2012 SP1 Beta with better results (time-wise), as we have fixed the code that was previously compiling all policies prior to installing each application.
Friday, November 9, 2012 4:00 PM
Whatever task sequence you're using on ConfigMgr 2012, you should be able to take that same task sequence and run it on ConfigMgr 2012 SP1 Beta with better results (time-wise), as we have fixed the code that was previously compiling all policies prior to installing each application.
This is nice to hear! Can't wait for the SP1 RTM.
Someone on this thread could confirm are the results really better with SP1?
Saturday, November 17, 2012 11:09 PM
Hey Jesper,
I've started putting the settings I've used up on my site. I just did Office x86 tonight, but this link links to the page they will show up in as I get them done:
http://www.geckostech.co.uk/?cat=84
Any input would be great. I clocked this office install at 4 mins, but it was on an SSD over a gig link.
MCP, MCDST, MCTS x 6, MCITP x 3
Please don't forget to mark this post as an answer if it is the solution to your problem!
If you like trance music, please subscribe to my podcast Trancendance Podcast
Follow me on Twitter
Tuesday, November 20, 2012 9:42 AM
Just clocked Office at 6 mins during OSD over a gig link on an old pentium dual core.
MCP, MCDST, MCTS x 6, MCITP x 3
Please don't forget to mark this post as an answer if it is the solution to your problem!
If you like trance music, please subscribe to my podcast Trancendance Podcast
Follow me on Twitter
Tuesday, November 20, 2012 10:35 AM
Hi Brian,
Thank you so much for checking this.
Our Office package configuration look quite similar but mine easily takes 12-15 minutes to install during OSD (also gig link).
Can I ask how big your Office x86 package is?
Thanks.
Wednesday, November 21, 2012 10:52 AM
735Mb
MCP, MCDST, MCTS x 6, MCITP x 3
Please don't forget to mark this post as an answer if it is the solution to your problem!
If you like trance music, please subscribe to my podcast Trancendance Podcast
Follow me on Twitter
Wednesday, November 21, 2012 11:07 AM
Ah, mine is 1300 MB...
Wednesday, November 21, 2012 11:14 AM
What sort of total deployment time are you getting?
With reference image, Office, Flash, Shockwave, Lync and Updates etc mine is about 45 mins.
MCP, MCDST, MCTS x 6, MCITP x 3
Please don't forget to mark this post as an answer if it is the solution to your problem!
If you like trance music, please subscribe to my podcast Trancendance Podcast
Follow me on Twitter
Wednesday, November 21, 2012 11:18 AM
A few more apps added in my setup but quite similar. I end up with 1.5 hours. Office alone is 15 minutes.
Wednesday, November 21, 2012 11:22 AM
I'd love to see what sort of speed improvements there are in SP1 in this case. 45 mins is about the same as we were getting for the fully built image from WDS!
MCP, MCDST, MCTS x 6, MCITP x 3
Please don't forget to mark this post as an answer if it is the solution to your problem!
If you like trance music, please subscribe to my podcast Trancendance Podcast
Follow me on Twitter
Thursday, November 29, 2012 8:44 PM
So any progress on this one? Any better results RTM vs SP1 beta?
Thursday, December 6, 2012 1:15 PM
Now I ran to this same problem too. I don´t know, what has changed in my enviroment, but suddently installation of Win7 with update steps and few application started to take more than 5 hours!
I imported updates to Win 7 .wim file with offline servicing, and disabled software update steps. Still applications are installed very slow, and computer´s hdd activity led is not active all the time, only half.
I will try to dig up something from smsts.log, but doesn´t it get empty few times during installation? Even smsts-date.log file is not entire.
Thursday, December 6, 2012 3:14 PM
As mentioned above (I think), this is essentially known behavior in RTM due to the way they are handling/over-handling policies on the client. There really isn't much you can do until SP1 except to not include updates in your TS and use offline servicing instead.
Jason | http://blog.configmgrftw.com
Sunday, December 9, 2012 10:40 AM
Intresting thing is, that same applications runs fine in x86 task of Win7 installation, but suddently this problem occured in x64 W7 installation. Some time ago all worked fine.
Friday, December 14, 2012 1:53 AM
Thanks Jim. As long as it's "fixed" in SP1. :-)
Jason | http://blog.configmgrftw.com
Friday, January 4, 2013 8:09 PM
@skeiffer - Excellent! Glad it seems to be working better for you. Thanks for trying it out and letting us know.
Monday, January 7, 2013 9:08 PM
We just got our environment upgraded to SP1 today as well and appears to be working great for us too. So much faster. Thanks.
Wednesday, January 9, 2013 10:32 AM
Very glad to report that this is resolved for us too now that we've updated to SP1.
Wednesday, January 9, 2013 5:51 PM
Dumb question, but where can I download the RTM? I see links for the BETA all over, but not RTM.
Wednesday, January 9, 2013 6:16 PM
You can get it from Microsoft Volume License Site (MVLS) or the Microsoft Partners site, or if you're a Technet or MSDN member it's available for download there too. No publicly available evaluation version just yet as far as I'm aware.
Wednesday, January 9, 2013 6:24 PM
Thank you, just saw it under my MVLS profile.