Rocket Man

Good stuff.....Does this works with SCCM 2012 SP1? Can it be installed on a client OS or does it have to be installed on site server?

You should be able to ping it via FQDN which is very important, you may have a DNS issue in this particular VLAN that the test system resides. For a test can you spin up VM on the server VLAN(SCCM site Server VLAN) and test this to see if it is successful at connecting to the site server to pull down TS policies. Have you deleted these unknown objects from SCCM prior to trying your TS deployment again?

Is your system getting a DHCP address at this stage before it reboots and can it ping the FQDN of the site server/DP?

Here's one I would really like to see: Be able to right click on a specific system and send a TS or a package right to it....instead of having to move the system into a collection and targeting the collection!! Is this possible?? Maybe it already exists but I have not came across such a feature yet!! I am sure other SCCM admins would love this feature if it was possible!! Thanks Rocket Man

I am looking at one of my removed site systems that did only act as a DP and a site system and all the directories are also present....but IIS has removed the virtual directories from it's console....and the procedure I used to remove the DP was as follows: Removed all packages/apps manually from the DP(checked to make sure all content was removed by browsing to the content directories in the SMSPKGC$. Removed the PXE settings(Made sure that the WDS server role was completely removed after the PXE settings on the DP) Removed the Distribution point site system role. Deleted the site server which removes the site system role also. I guess the deletion of the rest of the left-over directories is a manual process if you intend keeping the server for other purposes...I am blowing away all the DP servers and starting afresh with server 2012 so the manual deletion is not applicable to me!!

Below are the locations the log file will be in depending on what stage the TS is at: During OS Deployment Before your hard drive is formatted and partitioned X:\windows\temp\smstslog\ After your hard drive is partitioned formatted X:\smstslog\ and then is in C:\_SMSTaskSequence\logs\smstslog\ Within Windows Within Windows before the SCCM agent is installed: C:\_SMSTaskSequence\logs\smstslog\ Within Windows after the SCCM agent installed: C:\windows\system32\ccm\logs\smstslog\ When the Task Sequence completes on a x86 C:\windows\system32\ccm\logs\ For x64 Systems C:\windows\SysWOW64\ccm\logs\ You will need to enable your boot.wim with f8 support to retrieve the log if it bombs out before apply OS stage so that you can bring up the command prompt and copy the log to a share on the network.

You will have to get in touch with Microsoft to find that out considering if there is nothing on the web about how to properly do it OR someone else may contribute on how to do it other than that stated above which is the only way I know and may very well be the only way to do it! If you hear anymore about it do report back as I am currently removing multiple site systems from an SCCM hirearchy and have another 6 to go soon and would be interested to know if there are any other ways.........but on the back of that there are no errors in SCCM from the previous 5 site systems I have removed! Rocket Man

Is this not normal? Any server that is going to hold any type of role with regards to SCCM is a site system by default(nothing you can do about that) If this server is not going to be used for any type of SCCM work in future then just delete the server at the server level!

There should be no need to add hyper-v drivers......the only drivers I ever inject into the boot.wim where the Dell winPE3.0 or 4.0.....and the very odd network driver for rare models. Can you try and deploy a standard deploy TS(not B&C) and attach a windows7 or windows8.wim directly to it to see if this has a different outcome. It could be the OS installer package you have created that may be corrupt so then.... It is an OS installer package you have created for the B&C process?

So you are using a pysical machine for testing purposes?? Have you attached the correct driver bundle specifically the network driver?? There are alot of errors in that snippet stating that it cannot find the appropriate drivers to match your systems hardware. If the system has no active NIC then how can the device find the content share where the client package is if it does not have a network driver installed after the OS is applied?? Have you started the machine into windows after the client has failed? Does it have an active NIC??

Just a thought also have you configured your Network Access account....looking at your failed snippet I see it has an error of 0x80004005........this could be the fact that the system is unable to get the data from the shares!!

Below are the locations the log file will be in depending on what stage the TS is at: During OS Deployment Before your hard drive is formatted and partitioned X:\windows\temp\smstslog\ After your hard drive is partitioned formatted X:\smstslog\ and then is in C:\_SMSTaskSequence\logs\smstslog\ Within Windows Within Windows before the SCCM agent is installed: C:\_SMSTaskSequence\logs\smstslog\ Within Windows after the SCCM agent installed: C:\windows\system32\ccm\logs\smstslog\ When the Task Sequence completes on a x86 C:\windows\system32\ccm\logs\ For x64 Systems C:\windows\SysWOW64\ccm\logs\ You will need to enable your boot.wim with f8 support to retrieve the log if it bombs out before apply OS stage so that you can bring up the command prompt and copy the log to a share on the network. Considering your TS is bombing out after the OS is applied but before the installation and initialisation of the agent then it should be in the latter of locations mentioned above! Good Luck!!

Yes...you can edit the distribution settings of the deployment to access all content from DP instead of downloading locally first.... Take note if this option is not available to you then all or some or even maybe just 1 package has not been configured to copy to the content share!

The smsts.log is the log that you should be looking into. You can deploy an x64 OS image with an x86 boot.wim.........but apparently not the other way around. I also read somewhere that if you are deploying custom built OS images then you should only use a 32bit boot.wim........if it is a x64 OS from an OS installer package then you use the x64 boot.wim! BTW you have distributed this package and it is has been configured to copy to content share on your DP(s)? Rocket Man

If you have unknown computer support enabled then yes. If you dont then you have to import the systems info(MAC and NetBIOS Name) into SCCM to allow it to PXE boot which the means your MAC address is no longer unknown. The first option is the easiest and most efficient way......with a DP password and a TS password it is almost as secure as a DP that does not allow unknown computer support!

Does configuring the configMgr client properties to the actual FQDN help any? i:e SMSLP=Server01.local; SMSMP=Server01.local Also you could try and use an x86 boot.wim image instead of the x64 boot.wim! Your selected configMgr client in your TS above is the one you created from definition??

Is anything working....you need to provide us with more info.... Are you using a virtual machine or a physical machine for testing purposes? If it is a virtual machine you are testing on then you can rule out possible mismatch driver. This error 0x8007002 translates into " The system cannot find the file specified" So it must be some sort of connectivity issue you are having. The network access account you have configured has the appropriate permissions to the location where all these files are stored? You have specified to copy the package(s) to the content share by configuring the package(s) properities before distributing and have you checked the content share folder on the DP itself to make sure the packages are present?

Semi-Famous? Thats an under statement....defo famous in sharing your knowledge of SCCM to the rest of the world......hats off to you! Rocket Man

Have you also injected the network driver from within the driver pack into the boot.wim........injecting the winPE 4.0 into the boot.wim is one task but you also have to inject the network driver from the driver pack also... Have you done this??

How large is this package? How are you deploying it.....Access from DP or download all content? The error 0x87d01201 translated means "The content download cannot be performed because there is not enough available space in cache or the disk is full" Can you try and manually change the cache size on a client to suit that of the size of the package, just make it larger to be on the safe side......so if your package is 8GB make the cache 10GB.....this can be done using right-click tools or scripts or manually via control panel on targeted machines!

I do not think it will work on server 2k8R2 according to other bloggs I have came across.....SCCM 2012 must also be atleast SP1 CU1 or later!! But if these bloggs are true which I can only imagine they have to be then how did you already achieve the above if your DP/PXE is 2K8R2???

Are there multiple DNS enteries with the same IP address? i:e ComputerA 192.168.0.55(Out dated) ComputerB 192.168.0.55(Out dated) ComputerC 192.168.0.55(Current system holding on to this IP address) You should be able to ping your laptops atleast by IP address once they are connected to your network not unless your WAP does not allow ping. Have you also tried what Peter suggested? Not sure if this matters as I have pushed out CM Agents accross wireless network connections with DNS enteries pointing to wireless IP, just once the IP address matches the current netbios name within DNS and there are no other out dated enteries with same IP address.

There is a new maintenance task that tidies up expired updates automatically and it is enabled by default maybe if you disable it. When on the topic I thought that this just removed expired updates from your deployment packages but I have noticed that my WSUS folder which I created at the initial setup of SCCM 2012 SP1 is empty also, it just has the UpdateServicesPackages and WSUScontent directories but no sub directories containing any WSUS data/updates etc... If I compare this to any another separate sites sitting on SCCM 2012 Non-SP1 the WSUS folder has approx 28GB of data still in it. So you have to question is this normal behaviour in SCCM 2012 SP1 to have no data in these folders (Which i thought there was data in initially) or is it a problem, everything seems to be working in relation to software update ADRs' etc and monthly pull downs, but why is the WSUS folder empty? Anyone else see this?

What is your DNS like?? Try and turn off the firewall on a single machine then ping again to rule out if it is firewall related or not! Had a similar problem with a CM2007 setup a way back. I introduced CM2007 on an already established network........couldnt get most of the clients to install even though the firewall exclusions were created on the local machines via GPO.......turned out to be old outdated DNS enteries....had no DNS scavenging turned on....so basically when I would manually try or let auto-site-wide installs to take place it would fail miserably because several machines had the same IP address according to DNS even though everything else was working fine in terms of ADDS. This seemed to get SCCM confused!! Rocket Man

I see that now......and you have injected in the x86 winPE drivers within the HP winPE package into your x86 boot.wim? You do not inject in the x64 winPE in to the x86 boot.wim!!