Peter van der Woude

You might be able to work something out with status filter rules and running a script, but the big question to me is, why? If you don't want the user to install the software, simply don't make it available...

Not sure what you are exactly looking for... Are you looking for a way to deploy user targeted application during the task sequence? If so, have a look at this: http://www.petervanderwoude.nl/post/install-user-targeted-applications-during-os-deployment-via-powershell-and-configmgr-2012/

Is that distribution point able to sent other state messages to the site server?

In general a new feature will be added to Microsoft Intune, before it comes to the integrated solution (there were some exceptions with profiles before).

No, you don't need to implement steps in your task sequence for installing certificates. During the deployment it can use the distribution point certificate, if required.

The name distribution point certificate, doesn't really cover the main usage. The main usage is for clients during the PXE deployment. For more information see also: http://technet.microsoft.com/en-us/library/gg699362.aspx

I thought it's the GUIDs in the manifest.xml. It should be explained in this paper.

It indeed looks pretty straight forward. For error messages indeed look at the execmgr.log. Another idea would be to run the batch file with PSEXEC to test it with SYSTEM credentials.

Did you just install it and simply left the configuration to ConfigMgr? The idea is that the distribution point will configure WDS when the PXE option is selected in the distribution point.

Did you configure the client settings with Computer Agent > Install permissions to either All Users or Only administrators and primary users.

Yes, but only as a separate update. See for an example: http://www.petervanderwoude.nl/post/publish-cumulative-updates-of-configmgr-via-system-center-updates-publisher/

No, in ConfigMgr you always have to target a collection.

Use an old-school package and configure the program to run with the user's rights.

As long as you're not installing a client on those machines, via the production environment, you should be fine.

Here is the documentation about the software updates, that should definitly get you started: http://technet.microsoft.com/en-us/library/gg682168.aspx

There are two types of driver that could be required in your boot image. The first one are the network drivers, to make sure your device can connect to the network while in WinPE, and the second one are the storage drivers, to make sure your device can access the disk while in WinPE. You should only add those drivers to the boot image when they are realy required. When you've got no problems with connecting to the network, or accessing the local disks, you do not need to add the drivers to the boot image.

Yes, the install wins; I don't think I would want to target the double amount of deployments to many users. I would try to make the uninstall deployment collections a bit more restrictive. Search for the installed software on the users primary device in combination with the membership of the user.

The client will pickup the secondary site MP based on the content location boundaries. For a very good read see: http://blog.configmgrftw.com/secondary-sites-and-boundary-groups/

You should add storage drivers to your boot image when you're having problems writing and accessing you disks during the applying of the image.

When you added the drivers via the ConfigMgr console, you should be able to very the drivers in the boot image via the properties of the boot image. The tab Drivers should display them.

[There are no more volumes available for use.] >> Make sure the partition is working as expected. It looks like it can't find a suitable drive to apply the image.

You can't copy the initial data manually. Also, don't forget that the main part is sql replication now.

I've been with customers were we used it to reimage classrooms at the same time. These were classrooms of 20-30 machines simultaniously.

Make sure the client object is active and in the right collection. If that's the case start looking at the client log files. For a complete list of all the log files, see: http://technet.microsoft.com/en-us/library/hh427342.aspx#BKMK_ClientOpLogs

Makes sense. Not everything can handle a bigger block size, that's why you should always test this very well when used in a production environment. For an example of a situation that doesn't work, see: http://www.bctechnet.com/vmware-pxe-limitations/