Rocket Man

Are you directly adding PCs to collections? Probably better for your situation to use a query rule to query the collection specific OU in AD. This way the systems will always stay in their collections in the console even after imaging. Why do you have to add the computer names again if they are already in the configMgr DB....this should not be the case...they should hold onto their names even after OSD...

That's because when you make a change on a package in other words you are updating the package for whatever reasons i:e new files etc...then all you have to do is right click on the package or use the ribbon located across the top of the console to update(not redistribute) any DPs that the content is already stored on.........To fully test your problem just create a new dummy package and then try to distribute it out....it should then bring up the DP list as it is new and has not been distributed yet! As for your DP storage as Peter has said it depends on the amount of content you need...how many images/software/update packages etc...It is best practice to consider and plan all of this before implementation especially on a production environnment

This is all you should be seeing in either case: Have you tried entering in the FQDN of your site server on a browser eg: http://siteservername.domain.local

Have you tried basic troubleshooting like checking that you can browse to to the admin shares of the problematic systems \\PCname\admin$ from the SCCM server and also run the wbemtest.exe to see if you can connect to the systems namespace this way. Prior to setting up this installatyion of SCCM...did these systems already exist on the network? If they did what you can try to do is delete the DNS record of these systems and reboot them to get a new fresh DNS record and then try the client install again.

Are you sure that this model's NIC driver is injected into the boot.wim? I have seen this before and all be said I found it a bit strange especially when it was able to PXE boot and install the OS....but after a reboot it failed as the NIC driver was not installed and the TS could not connect to the DP share to install any further software. A simple load into the OS after failure and an update device driver from device manager and point it to the Driver Package on the DP proved that the package was good. A reference taken to the manufacturer of the NIC driver and a check in the driver pool and an injection of this driver into the boot.wim solved this problem for me. I say this was strange as it did PXE boot fine before this injection...but obviously it must of used a different driver from my previously injected winPE3.0 bundle and then after the OS install part of the TS and restart it lost it's connection as it was not the correct driver...it even did not install the driver package associated with this model with appropriate WMI query before the restart..

Hi Mickey This sounds good..but what I gather from a quick research is that this installs a fully operational test lab of SCCM/ DCs and MDT? Am I correct in this? If this is the case what about labs/production environments already with SCCM implemented?? Does this KIT not require to be setup alongside the initial setup of SCCM? Have you ever just used a standard RTM install.wim from the media and deployed it? I am quite positive you will end up with an OS installed on a D:\ partition! There are numerous bloggs reporting this problem all over the web...and the fix is to B&C or a standard media capture of a previously deployed OS and then deploy the new wim and it will install on the C:\ partition.....SP1 I think resolves this...well for windows 8 deployment..not sure about windows 7 as i have not installed SP1 as of yet..as it is BETA and I have demolished my testing lab(must try this Hydration kit to get a test lab up and going again) Cheers

Is it on the DP share inside it's ID folder? Have you distributed both boot.wims(x86 & x64) to DPs? Have you tried removing it from DP and then individually distribute it back out (not via full TS)?

Have you specified to deploy it from the PXE server also??

Well if you created the 32bit image TS??? you should have no bother creating a 64bit image TS Ray as it is the same principle only that you use the new 64bit image and also 64bit boot.wim

Hi The standard boot image that comes OOB with the SCCM install is suffice for booting a VM...you do not need to add any drivers to the boot.wim in order to get a Virtual Machine to boot into PXE.......it is only some physical machines that need the NIC drivers injected into the boot.wim for a successful PXE boot. Did you inject the DELL winPE3.0 driver package into both x86 and x64 boot.wims?

Yes and dont forget to change the recovery mode from full to simple also !!

Double check your network access account...........does the TS partition and format HDD and then bomb out?

Hi does this mean that 1 deployment package will do instead of creating a new one each month........will it automatically add new win7 updates to the package from SCCM/WSUS and then on the 3rd Tuesday each month automatically update the DPs and then the clients on the machines will pole policy looking for new updates and automatically know that there are new updates(this months) in the same package it recieved updates from last month????

The build and capture idea may not be possibe without DHCP and as is PXE booting (maybe someone can confirm this to be true?).........You will more than likely have to manually build your custom version of server 2k8 preferably on a VM(recommended) and then use a standalone capture media to capture the image

Looking at the TS snippet, it looks like a standard TS..... just with a driver package added.......... Does it restart after apply OS then again after apply net settings?? It should not do this.....as mentioned before the 1st restart with a standard TS should only happen after the setup windows and configMgr Component.....the last component of your snippet.... Maybe create a new TS and add your driver package!

Is this normal behaviour?? It should not reboot after applying OS and before net settings/apply drivers! The 1st time it should reboot is after setup windows configMgr component of TS! Not unless you have manually added a restart component to the TS at this stage?

Isn't there a bug in 2007 where by you remove drivers and try and import them back in and it alerts you they are already imported....do a search for it there is a hotfix as far as I remember. Had to do it myself sometime ago.

Do your clients have the site code??

Yes but you can have 3 seperate advertisements for that package 1 on a Monday to occurr every week at a specific time, 1 on a wedensday to occurr every week at a specific time and the other of Friday with same settings.. You can create as many advertisements as you need.....I have a package I deploy every day at 5pm, 5:45pm 10:00pm 10:45pm and each Friday it deploys at 1:00pm along with the other settings!! EDIT: also make sure to select to always rerun program in the schedule settings!

You should be able to schedule it for whenever and whatever times you want?? Days, weeks Months and any time of the day, schedule to happen once, all the time, expire the deployment at a certain day and time....

Could be their network is of higher spec than yours maybe? Just sounds like symptoms of response/connection times to me also client hardware plays a role in this too i:e fast ethernet NIC vs GB NIC etc...

Ok so you rename them also because of the above after they have failed and you then PXE boot them to get them imaged.......are there any entries like MININT-XXXXXX in all systems/AD.....it could also be that there is a duplicate entry for these PCs MAC addresses... Does the new naming of the computers update in AD or is the old names present there also?

If possible....... but isolate the problematic PCs(if you can remember which ones failed) into a seperate collection and push it out to the live OS.......just to rule out that there is nothing weird happening on your network(connectivity issues.etc) at time of OSD to full collection. I doubt it is Boundary related nor NetAccess account related if some pass and some fail and all machines are on the same subnet/physical LAN/switch....if it was either BG or Net Account then it can only be assumed that all would fail.....right? Just out of curiosity....Are all machines same model that are in this collection??

Is it the same machines that are failing all the time or is it different?? Have you isolated these problematic PCs and tried the forced client OSD install to see if they still fail?

You say you can ping these computers from Primary site but can you browse to the admin shares on the problematic computers i:e \\PCName\admin$ if not then you may have a WMI issue. Also try wbemtest.exe from Primary Site to try and get into the namespace of the problematic PCs....again if this not work either then you definitely have a WMI issue with these PCs.. Have you tried this?