Peter van der Woude

Are you using USMT? If so, check the loadstate.log and the scanstate.log for more information.

You need to provide more details about the failures that you are seeing (logfiles etc.).

It's indeed expected that with any additional Software Update Point, you can't configure those settings. Every additional Software Update Point will automatically use the first Software Update Point as up-stream server and will use the same configuration for categories, products, etc.

If you mean a stand-alone media, that contains all the required content. That's the whole idea of that media. Are you using custom scripts that download additional stuff? If so, you can look at the _SMSTSLaunchMode task sequence variable, which contains the required information.

If RegionValue is an exact match to what you need, then the answer is yes.

Based on the log files it looks like it's trying to connect on port 443 though...

You've got the run the software update scan cycle on the client, to get its up-to-date information about the installed products and applicable patches. After that trigger the software update deployment cycle and it should find the applicable IE11 updates.

I would start a discussion with hiim about this almost crazy request. If you really want to migrate it, you've got to add the cooky location to the XML files that you use during the capture of the user state.

If you don't have the Windows Firewall enabled, you don't need to create those settings in a GPO, or locally. Just make sure that the required ports are open on the network-level. Only the ConfigMgr site server needs permissions to the System Management container. The database server doesn't have to write anything in that container.

Why would you want to migrate cookies? This is one of those moments that I would be happy to finally get them cleaned up....

1622 is related to opening the log file. Could it be related to the backslash behind the name of your log file?

Just double-checking, you are aware that this is an Application and not a Package?

This should get you started: http://damonjohns.com/2015/09/28/windows-10-implementing-custom-branding/

If you try, even a little bit, you can see that it's all about registry keys and values.

Is it getting that information from the AD? If so make sure that the AD is updated. If not, make sure that the management point upgrade was succesful.

Haven't tested it. I would simply test it in a lab environment and try XP with an old client and XP with a new client.

There you go: https://technet.microsoft.com/en-us/library/gg712298.aspx

The client provides the updated version number during the next heartbeat discovery. Depending on the schedule of the heartbeat discovery, this might take some time.

Small note, not supported doesn't mean that it doesn't work.

Works like a charm. What kind of remarks are you exactly looking for?

Depending on the exact scenario, I would probably put the ConfigMgr client in the image. There is a TechNet article that explains how to clean the client before finalizing the image.

That error is often certificate related.

I assume they've created that account to perform the installation with. The installation only creates the local group of SMS Admins.

You can run WSUS and a SUP in the same environment. You just have to make sure to target the right GPO and Client Settings to the right clients. In this specific case you can even create a script to scan against WSUS during the task sequence.

You could follow the Exchange team blog for information about released updates: http://blogs.technet.com/b/exchange/