Rocket Man

You'd probably need to look at MDT integration and UDI to achieve this. This would give the end user a choice of software etc... that they wish to install. Another way but is very similar to above is to use collection variables...so if you have finance department computers and finance apps ....simply define collection variables so that the finance apps only get installed on the finance computer collection during OSD.

I do believe IP helpers help clients know where and what the PXE server is..... so maybe not your issuse but it seems like your systems cannot find the boot files! I take it that you have deployed your TS to the unknown computer collection as available and that you have also specified to deploy boot images from PXE server?

It is not a network (VLAN) issue if the same happens on a VM that is on the same VLAN as the servers. The log compains about MP issue, possibly not been able to communicate with it. If the site components and site systems roles are all green then just check your mpcontrol.log just to be sure.

Never seen a setup before where by the DHCP server was isolated on a different subnet than that of the server(s) VLAN. Maybe IP helpers or DHCP relay needs to be configured (not DHCP options).

what network do your clients reside on?

Hi Vince The PXE flag is actually quite useful in deployment scenarios, actually very useful. When you first image your unknown machine it wont be set as previously mentioned. However when you get all your systems into desired collections you can deploy a task sequence as required via PXE to a collection if you are refreshing them. Once the systems get's this deployment it will set a PXE flag. Now here is the beauty of this. You can set your Task sequence deployment to only deploy via PXE and boot media (if of course on 2012 SP1 atleast) and to always rerun. This means that this task sequence will always rerun on the collection, but only via PXE or boot media. So no-more creating new Task sequences and re-deploying. Whenever you need to refresh your systems that have the PXE flag already set from the initial required deployment just simply clear the flag and press f12 and watch it re-image. On the other-hand when the PXE flag is set and a user accidentally presses f12 on a machine it will not PXE boot because of the flag being set even though the deployment is set to always re-run but only to media and PXE. PXE flag is a pretty cool and important part of SCCM and once understood and used correctly it will mean less time creating and re-deploying of task sequences, and now with 2012 SP1+ with the new deployment options i:e only PXE and boot media makes it even better and more valuable!

A known computer should not PXE boot to a task sequence if the PXE flag has been set initially. If using unknown computer support for the 1st time the PXE flag will not get set and also the available task sequence which was used to image the unknown computer will also not be available anymore considering the system is now known (it has an entry in the CMDB). If you delete the system from SCCM it is unknown again and will (should) pull down any task sequence targeted at the unknown computer collection. If you are importing computer information (which I think is the method you are using) and not using unknown computer support then to get the machines to image again via the PXE method is to clear the PXE flag on the required system(s). i:e right click on collection or individual system and select clear PXE flag. Maybe you already know about this, but if not then this maybe your solution..

How are you applying drivers.... are you using a WMI query on your attached HP 6000 driver package and then also have a standard apply drivers task that will choose the best matched drivers also?? Have you tried imaging a VM just to rule out a driver issue? If it was an issue with your NAA would the apply OS and drivers portion run? I would think not. Also your domain join account does not have to be the NAA it can be any user that has domain admin rights...maybe create a new user who's task is to join machines to the domain during OSD and plug in these credentials to see if it makes a difference.

Check bios system date/time settings.

Well that is possible but I am not sure about the driver part. You could specify your deployment to access all content from DP which will allow for the OS to be installed via accessing from DP then for your packages you could copy each one locally and execute them locally via run command line. The driver part I am not sure as there is more going on to an attach driver package task behind the scenes.

Yes it would be a reason.....my Task Sequence fails at some packages if i download all content as my packages are designed and built for accessing from DP first!

Just after checking this out and same problem also: Hyper-V 2012, DP on Server 2012......chronic download speeds even testing on a VM that sits on the same Virtual network switch as the DP. It seems fine if you specify to Access all content from DP which is the setting I use but just wanted to check this out and it seems to be a problem that has just arose from the upgrade to R2 as this has been tested before on SCCM Sp1 without any issues. 50% downloaded and 5 mins have went past on a 2gb wim.

You can upgrade to R2 directly after SP1 and then enable upgrade client. Should be fine. Dont think there should be any need to upgrade clients twice.

Yes all remote DPs are running server 2012. After doing 3 more WDS service restarts today at the other remote DPs and imaging is working again via PXE at these 3 again also.

After upgrading to R2 on two sites. One site has 10 remote PXE enabled DPs, none of them would PXE boot initially after the upgrade, but a simple restart of the WDS server from within the WDS console got them all working again. Did you at least try this before you went about removing roles etc?

What would happen if you dont specify update rollups in the classifications of the SUP configuration? It should not install ie10 as this is an update rollup from IE9. If you ever decide to roll it out deploy it as a package and the standard security updates will come down for it regardless if update rollups is not specified. This is the configuration I have set at the moment and so far no ie10 has installed automatically and I see that there are security updates for ie10 in my windows 7 ADR. So if I do decide to deploy it out then the security updates are there for it.

You can be assured that it will work! The task sequence method that you have posted above would be the way to go, as stated just change the copyfile.bat portion to: xcopy ".\*.*" "C:\Program Files" /D /E /C /I /Q /H /R /Y /S p.s send some sun this way!

And the site is published in site settings?

Hi Crossed wires here. If you are just using package with batch file then the name of the program commandline (my mistake ) would be the name of the batch file but you must make sure that the batch file is present in the package also with your file. The above screen shot is good only if you add xcopy ".\*.*" "C:\Program Files" /D /E /C /I /Q /H /R /Y /S as the command and not filecopy.bat

This is the System Management Container you are talking about?

Just create a package with the file in it and a batch file also. The batch file will look like this copy %~dp0myfile.file "C:\Program Files" /y The run command line for the package program would be the name of the batch file. OR Create a package out of the file, distribute to DP and in your task sequence add a run commandline task that references your package and the command line would be: xcopy ".\*.*" "C:\Program Files" /D /E /C /I /Q /H /R /Y /S

Did you manually configure WDS in anyway? DHCP options are definitely not needed in a single VLAN network.

That guide is for SP1 to R2. Not sure if it is a supported path to upgrade from non-Sp1 directly to R2. But there would be no need to start from scratch as you could first upgrade to SP1 first and then to R2. Here is the guide for upgrading to SP1 first and then you could use this for upgrading to R2 bearing in mind to download the RTM versions first.

You are using DHCP options (not recommended and unsupported by Microsoft). The thing is it will work (for a while) and then eventually you will see the line in your PXE boot attempt USING DHCP REFERRAL. You will have to configure IP helpers, to overcome this issue.

What about DNS, are these machines updating their DNS records? Possibly could be outdated records for these machines if so DNS flush them or better again delete the records manually and log them back in to generate new records and try the client push again.