Peter van der Woude

You shouldn't manually import device that already have a client. These devices will get discovered, as you have noticed.

The installation of remote site systems work the almost same. Just start with the Create Site System Server Wizard and during the wizard select the Roles you want.

When the client are installed correctly they will automatically switch between intranet and internet. See also: http://technet.microsoft.com/en-us/library/gg712701.aspx#BKMK_PlanforInternetClients

Small note: Offline servicing can not be used for Office updates.

Then start by looking at the exact error message in the SMSTS.log

There is no buildin feature to rollback/uninstall/recall an update. As soon as it's installed you need to create your own uninstall package/action. When it's not installed, yet, just remove/retarget the deployment.

Did you check if the content is really on the DP and that your client is within the boundaries?

It's a combination of tuning your maintenance tasks and cleaning your ad, otherwise it will keep on discovering the old machines...

You can use a combination of this post http://www.windows-noob.com/forums/index.php?/topic/3034-how-can-i-deploy-office-2010-professional-plus-using-sccm-2007/ and this post http://blogs.technet.com/b/meamcs/archive/2012/05/08/deploy-office-2010-using-system-center-2012-configuration-manager.aspx

Correct.

At this moment ConfigMgr can't reuse (doesn't support) existing WSUS environments... So you need to create a new WSUS installation for your SUP.

Nope, a Site Reset does not resolve issues with shares, see also: http://technet.microsoft.com/en-us/library/hh427336.aspx#BKMK_SiteReset

The client will look at its assigned DP for the content of the client package. Also a small add-on at your initial question, with SP1 it will be possible to have another SUP at a remote location (http://technet.microsoft.com/en-us/library/jj591552.aspx).

You could look at a simple/ basic HTA

What problems are you running into? The only thing I can say based on your information is that I would also put the iss file in the package.

If you can't do a nslookup of the FQDN then it's almost certain a dns problem...

When you have an old school package with multiple programs you deploy a specific program. If you want to link the programs within a package you need to configure that in the tab Advanced of the Properties of the client.

Now you have to start looking at logs like, CAS.log, DataTransferService.log and FileBits.log.

Since SP1 the build-in collections are read-only and cannot be modified

You can look at something like AdminStudio, but that's not for free...

It looks like the same thing that happened as with ConfigMgr 2007, the step times out with a lot of updates. Try adding another Install Software Updates -step, like explained here: http://support.microsoft.com/kb/2009754

As an add-on, the PXE password can be removed in via the properties of the Distribution Point and then the tab PXE.

I wouldn't make the 32-bit version a dependency for the 64-bit version... Just use requirements to make sure which version can install on which OS.

Are you completely sure you made the update available to a collection in which the machine exists?

Did you check the component status?