Peter van der Woude

Yes, you can run a task sequence on a laptop with Windows 7 installed, as long as the client is already installed.

The only method I can think of, right now, is using multiple packages and depending on the script configure them to run as admin (system), or run as user. Then chain these packages by selecting run another program first and deploy the last package in the chain.

I would start by looking into the client log files.It sounds like the client isn't communicating with the management point, yet.

The client log files, you should still be able to find some information in the execmgr and the smsts log files.

It simply calculates the hash of the files in the content library and validates those with the hashes in the databases. It doesn;t do anything with the data itself.

You can deploy those other updates the same as you deploy your operating system updates. Simply download the updates to a package, add them to a update group en deploy that group.

Check on the client site (log files) if there is really still an evaluation task running.

Those updates can also be deployed via ConfigMgr. In the software update component properties you can configure which products it has to sync. These products will be same as you can deploy via a standalone WSUS. Also, keep in mind that the software update point is still using WSUS to sync the metadata of all the updates.

Are all of those task sequences deployed to the same collection?

Did it complete the task sequence? Please check the deployment status and the log files.

Makes sense, as IIS is a core component of a DP.

Is this one of your machines [LOG[F0:DE:F1:BB:82:38, 3BA59081-5154-11CB-B87D-B0F660D4D999: no advertisements found]LOG]? If so, there seem to be some problems with finding deployments for that device. If it's truly in the right collection I would completely remove that device and try again.

So you're talking about deployments via PXE? If so, check the SMSPXE.log for more information.

You deploy the R2 client and then deploy the CU update.

Do I understand it correctly that you can't connect to the DP, from the client, since the move? If so, is the client resolving the DP to the right IP?

You could use Get-CMDeviceCollection to get the properties of device related collections.

Create a collection that includes the other two collections. There is no way you can do that during a migration job, so if you don't want to do that manually you need to script it.

Application deployments, or OS deployments?

Correct, the ConfigMgr 2012 site does not use the old information about the ConfigMgr 2007 site.

I can also share the experience of using the x64 boot image to solve black screens....

It probably will work to move the server when it's off... I would start by taking of the most intensive roles (or duplicating them), the DP, SUP and MP.

Slow network boundary still makes a distribution point the prefered one for a client, so that won't help you. I would say, make sure the content is not available on a prefered distribution point and that there is no fallback location available. For more information see: http://technet.microsoft.com/en-us/library/b2516212-e524-4031-9a1f-7b768084304d#BKMK_PreferredDistributionPoint and http://technet.microsoft.com/en-us/library/gg682083.aspx#BKMK_PreferredDistributionPoint

Theoratically a stand-alone primary site should easily be able to manage 10k clients, even with everything on one box. But like with everything it all depends on the specs of the box and everything around. The easiest way to offload some roles, is simply creating a new server and offload some roles to that server.

Also, to add-on, by default Internet clients will use Microsoft Update for their update content.

I would prefer the normal way of deploying updates, but in case you really want something different you could use a task sequence to deploy those updates. That way the user will only need to select the task sequence to deploy the updates.