Rocket Man

Apologies spgsitsupport my post was not aimed for you but actually for vitalstatistix with the post heading "Deploying SCEP during Task Sequence". I should have looked at the dates of the post :/

I do this when deploying workgroup machines. The CCM bits are located in the CCMSETUP folder which includes the SCEP installer. If you create a run command line task in your sequence any where after the agent gets installed with these parameters: C:\Windows\ccmsetup\SCEPInstall.exe /S This will install the SCEP client and when the TS finishes the client will pull the endpoint policies deployed to it, but as for getting definition updates immediately maybe you can force an update scan also after the SCEP installation but TBH in any environment I have seen, the SCEP client updates fairly swiftly 5-10 mins max, which is compliant enough for me in relation to a user using the system immediately.

If you have VLANs on your network you can simply add devices\VMs to same VLAN as DP and then see if you get same result. If deployments are successful on this network then you have a better case to bring to them. and they will have to do some digging.

Have a similar problem at one location with same symptoms as yours. I have put it down to network issue for now as if I test on 3 VMs on server VLAN it is successful all the time, but if I try edge VLAN with physical system deployment it is random. The same TS works in another location on same model no problem, so this leads me to believe its networking issue at this location. Maybe some members can add to this as it would be good to get definitive answer. For now it's a FAT image deployed at this location Error code 8007274c:

You distribute the deployment update package to the DP not the ADR, the ADR is deployed to collection. When the ADR runs its evaluation cycle it then distributes the updates + new updates out to DPs the deployment package is associated to.

Hi Sbuck Office 2013 SP1 has a known bug with lync and one drive for business when using the OCT so must be the same for xml deployment method also. TBH I use the OCT to preconfigure custom features this worked a treat with office 2010 and office 2013 non SP1. It only turned out to be an issue with the introduction of OFF2013 SP1 with one drive and lync. To save headaches what I have done is reverted back to using the Office 2013 non SP1 source files and used the OCT to create my preconfigured deployment options which included lync and one drive and then created a seperate package for the SP1 update and attached it directly after the Office 2013 non SP1 task in the sequence. This way I have lync and one drive on the deployed system and also SP1 update. Hope this helps.

Have you tired removing the additional restart task you have attached directly after the configmgr agent installation. The agent installation will restart by default (so no need for the additional restart step) and perhaps when it loads back up and initialises it does not have time to come out of provisioning mode due to the other restart?

Is this the same TS that originally imaged these active devices? How is it deployed to media/pxe etc and never run, always rerun etc..? If it's PXE have you cleared PXE flag if a flag is set that is? Have you tried creating new TS and deploying it out?

Also just to add depending on when your Surface was manufactured and the release\version of your driver\firmware package would depend if firmware gets updated as the surface may already be shipped with the latest firmware. You should see after the first restart when the agent gets installed that the device will display applying system updates, this is the newer firmware been applied to the older.(correct me if I am wrong)

Yes but please try 4000000kb and restart the application pool, monitor the logs. If 503 service unavailable error comes back increase to 8000000kb, keep increasing until hope fully the issue is resolved and depending on environment depends on increase.

Have you tried increasing the default memory to the below settings:

Like Garth has mentioned this should be based on number of clients at remote site. You have a fast link so software updates may not be throthling the WAN links presently as like software application deployments. PXE initiated OSD of PCs in mass across the WAN links with no local PXE enabled DP will hammer your link, this is expected. If you dont do that much OSD imaging at the remote site then why not go with USB deployment considering you have AD/DNS there etc replicating from Data centre. Get your techs USB built pens with your custom image, software etc.. or get the agent on the machines and stage the OSD Task sequence out to them, either of these options will leave out the slow PXE performance you are experiencing but again all depends on your remote environment i:e number of clients, how much OSD occurs etc... But at the end of the day it is a simpler solution to configure a PXE/DP for the remote site and enable for unknown computer support and F12 your machine as required to pull down a pre deployed OSD task sequence where all the software associated with it resides on a local DP where the system resides so only the local network gets throttled!

that is strange...no errors...must be a problem with the ieak then. Can you just for testing install ie9 or 10 manually on system and then re-advertise the ie11 application again and see if it installs. You can also create an application from the .exe also, but you will need to fill in the extra stuff like detection method, install params etc... this will probably work better, and looking at the blog link you posted in your initial post it seems a lot of users are having the same issue as your self.

Could be your detection method that you configured considering it's stating that it is installed. Make sure that the detection rule you use differs between ie8 and ie11, maybe try custom detection method as opposed msi product code. BTW your deployed system has been rebooted after installation of application? The command line used above should reboot as a norestart command is not in the command but just to make sure.

If its windows 7 have you tried with turning off the UAC completely?

How are you preparing your OS before the manual capture using the ISO capture media? TBH I have only used ISO capture media for my images as I have no need for FAT images(which I assume is why you are using automated build and capture) so that it installs OS, software, updates and any other custom tasks before capturing to a wim file. BTW are you targeting a virtual machine or physical machine with the B&C task sequence?

Have you tried using the Dell WINPE driver cabs for this model. http://en.community.dell.com/techcenter/enterprise-client/w/wiki/2065.dell-command-deploy-driver-packs-for-enterprise-client-os-deployment Currently the only WINPE driver bundle that I have used and it boots almost everything in the enterprise from all current DELLs including the 3020, HPs, Lenovos, Fujitsu's..... bar a few manufacturer devices. Depending on your version of SCCM depends on which WINPE version is supported i:e if your running ConfigMgr 2012 SP1 then use the WINPE4.0 cab, inject the x86 cab files into the x86 boot file and the x64 driver cab files into the x64 boot file.

You could try windows remote assistance, check it out it maybe what you are looking for. http://windows.microsoft.com/en-ie/windows/what-is-windows-remote-assistance#1TC=windows-7

It generally means that the task sequence did not finish with a successful code. I get this sometimes when I deploy an OSD TS and it fails at a certain stage, so I guess it is the same for the B&C Task Sequence. Do you have continue on error selected on any tasks of the sequence? This may cause it in particular if the last task in the sequence has it selected.

You can simply add the OR operator into the single WMI query as TrialandError mentioned for example: SELECT * FROM Win32_ComputerSystem WHERE Model Like "%35542S2%" OR Model Like "%model1%" OR Model like "%model2%"

You could try manually joining a number of workgroup machines to the domain with the same domain join account set in TS and see if this has similar issues, this way then you can rule out SCCM if it is the same? Has the user account set in TS for domain join been altered in anyway with permissions etc.. Has DNS settings changed i:e DHCP settings for clients to know what DNS server IP is You could also try and create a new TS with minimal software just for speediness with deployments to see if it works any better.

Is this the location of where it is supposed to be even after a manual install? and by nothing happens--do you mean it did not copy the file successfully to this directory?

How is this installed manually? Is there a directory created with the install of firefox or a plugin install i:e appdata\firefox\plugins or program files\firefox\plugins or something along the lines of this? It maybe just a matter of copying the disable_dhe-0.1.1-fx.xpi file to the firefox plugin folder location?

As you have configured 2 PXE enabled DPs then yes the client PXE booting from the remote site should see the IP of the local DP and not the IP of site server across the WAN link. How is your boundaries, boundary groups etc configured? Just make sure to add the remote DP to the correct boundary in the boundaries node.

You could import the computers information via MAC address to overcome this and add it to a collection that has the correct deployed TS architecture boot file added. This way if it fails you can just clear the PXE flag and boot again without deleting the computer object. Has PROs and CONs, Cons is it can be slow to gather this info and import, PROs is that if you are imaging in MASS you wont have to wait until all other systems are successfully imaged before you can associate and delete the unknown objects with the failed deployments.