Chris Nackers

There is absolutely no reason for a 5k organization to have a CAS, not a single valid reason. Separating the server teams and desktop teams is done via RBA, multiple primary sites will not give you separation as the data is global, it will be replicated between the sites. You also should not have any load issues with a 5k client environment if the server is configured properly. You can easily run all the roles including the database on a single primary site as long as it is configured properly. Here is a webcast i did on RBA, i would recommend watching it to learn how to seperate desktops/server teams. http://www.chrisnackers.com/2013/10/27/role-based-administration-tipstricks-replay-is-up/

It's stored in the XML in DB, it's encrypted. The task sequence is located under OSD - Task Sequences node.

You can simply use the existing WSUS server to install updates during a ConfigMgr TS. http://myitforum.com/cs2/blogs/cnackers/archive/2011/04/28/using-ztiwindowsupdate-wsf-to-install-updates-in-a-system-center-configuration-manager-task-sequence.aspx

have you imported the R3 reports? that is a manual step that needs to be completed.

what does the software distribution look like? what do the logs say? is the client receiving the policy?

when you distribute the boot image you should have a PXESHARE$ option, that is the PSP, needs to be there to boot it over PXE...

Did you add the boot image to the PXE Service Point? The log should be in x:\windows if memory serves

ok, then it's probably not the correct driver... if you look at the winpeinit.log you should be able to see the hardwareid of the NIC, you can use that to track down the correct driver

Are you referring to the R3 package that is created during the install? Did you remember to distribute that package to the distribution points?

drivers should be added/removed from within the configmgr console (boot image properties) if you are using WAIk to add drivers, then they need to be added to the winpe.wim file, not hte winpexxxxxx.wim file. If MDT has been integrated into your console, you will have a new option under the right-click menu for boot media and for task seqeuences called "Microsoft deployment...", MDT extensions are a PER-console basis.

Windows PE is based upon windows 7, so you need t inject the appropriate windows 7 drivers... then you will also need the appropriate drivers in your driver store for the OS you are working with (XP, Vista, Windows7). These would be installed via apply driver package or auto apply driver step. Again, for winpe to have a correct IP, you need the correct windows 7 driver added to the appropriate boot image. ConfigMgr SP2 is WAIK 2.0 which is windows 7 based WAIK 2.1 is windows 7 sp1 ConfigMGr SP1 is WAIK 1.0 which is Vista MDT 2010 uses WAIK 2.0 (win7) MDT 2008 uses WAIK 1.0 (vista)

Linked shares have their own customsettings.ini and bootstrap.ini, so you need to add the appropriate queries to those files just like you have for your primary share. Remember that any change to bootstrap.ini requires an update to the boot media for that share.

I haven't been able to sucessfully get it to work. I typically just copy the stock files and modify as needed. The issue is always the path and ensuring that path works for all scenarios, which is next to impossible.

I could mistaken on if it's possible, but off the top of my head, i don't think it is. not 100% though. I know you can do it without the SMP but with the way the SMP works, it doesn't surprise me that it's not working for you.

So your main issue is really a result of the disk encryption. Typically you would simply refresh the existing box in-place. This isn't possible do to your encryption, so you almost have to treat it like a replace scenario, old hardware to new hardware. When you PXE boot the machine, it's basically a new item, there is no associaton, that's where you're getting into a bind. It's not designed to do what you are trying to do with it. It's seeing the MAC is the same, so it's creating a new record, and thus the in-place assocation doesn't work. You would have to create an assocation to a new object just like new hardware, but since it uses the MAC, that's an issue. Another option would to not use the SMP and simply dump the user data to a network share.

the values set in apply network settings are simply passed onto the setup windows and configmgr step... have you tried setting the apply network step to join a workgroup and then doing a seperate domain join after the setup windows and configmgr step? It's possibly that route might work.

Do you mean the credentials prompt for MDT Lite Touch? Access is controlled by the permissions on the deployment share.

You can't deploy a x86 OS from a x64 boot image.

PXE should use the most recently updated image, try updating your x86 with a new source version and see if that works. (Just an idea, might not work) You need a x64 boot iamge on the PSP for a 64-bit machine to boot, however i want to say it will always use the MOST RECENTLY updated image, but i can't confirm that. Also, you can deploy both x86 and x64 OS's from a x86 boot image, so you don't really need to have a x64 image for TS's, but it needs to be on the PSP in order for pxe to work successfully. Also do you have any mandatory TS's? That will effect the boot image used as well.

It's probably using the x64 boot media to PXE then, and once you select the XP TS, it's flipping to the x86 boot media. If the system is 64-bit capable, a 64-bit pxe image might be used.

What boot images are distributed on the PXE Service Point? What boot image is set for the task seqeunce? (Task Sequence properties)

Is this ConfigMgr? What version? Is this physical or VM? You sure you don't have a cd/iso mounted?

Hope that helps.

It means the task sequence you selected has a different boot image assigned to it than the one used during PXE.

one scenario is backing up a users pc and then restoring that to a new pc. I don't think you would want to restore that to any other machines as it would contain user specific data that really shouldn't be replicated out. Plus any additional programs/changes she's made would be replicated as well. the other solution is creating a master "image" that you will use to build new hardware or refresh existing hardware. The scenario you described would be handled as a replacement scenario. You would run a user state capture on her machine, capture her user data, then do a "bare metal" install to a new machine, lay down your image, install additional applications and then restore her user state to that new machine. User State Migration Tool, is the preferred tool for capturing/restoring user data, this integrates with ConfigMgr, or can be used completely stand-alone. it's generally a good practice to put down a clean os image instead of imaging/backing up an exisitng users machine, any problems they have, would simply come along with that, from an IT standpoint, any chance we can get to get them a new clean OS, is a good thing to have. If you have a physical machine that you want to capture as the master machine, that is fairly easy to do. You need to create "Capture Media" from ConfigMgr (right click on task sequences and select create task sequence media), this media (Cd/dvd) when ran on the machine will sysprep and shutdown the machine and capture the computer to a network location as a .wim. It is HIGHLY recommended that the computer not be joined to a domain or have ever been joined to the domain, again as you are just increasing your risk of having issues with that "image", doesn't matter if it's ghost or otherwise, that's a general imaging best practice. Thankfully configmgr can inject mass storage drivers on the fly (xp), so you won't have to worry about adding drivers to your image prior to capture to be able to deploy that image to different hardware. The only thing that would come into play is the HAL of the machine, and HAL switching is not supported by microsoft. Hope that helps.