Setting the AD computer object description should be allowed inside a task sequence during the domain join operation.
Whether or not this is on the dialog box, is not important to me. I'd be happy setting a TS variable (ie. OSDComputerObjectDescription)

Alternatively, we could use a PowerShell script using different credentials (which Task Sequences also do not allow). Similar to the way
the "Run Command Line" allows the input of credentials.

Right now we have to use a kludgy "Run Command Line" using credentials and run
a batch file that calls something like: PowerShell.exe -executionpolicy Bypass -command pscommandhere
or: PowerShell.exe -executionpolicy Bypass -file .\powershellscript.ps1

PXE-Enabled DPs currently pass their Management Point List on to PXE Clients, as reflected in the "ManagementPoints" list in HKLM\SOFTWARE\Microsoft\SMS\DP; this seems to be an alphabetical list of MPs in the infrastructure which may not reflect the actual MP(s) the PXE client should communicate with.
On the PXE-Enabled DP, in HKLM\OSFTWARE\Microsoft\CCM, the AllowedMPs registry value can be created and populated. The PXE Responder will honor this list when setting up the PXE Client's environment.

A field should be added to the PXE settings of a DP to allow configuring of this setting, or to override the site's MP List that gets written to the MP and instead replace it with the administrator's defined list of MPs relevant for the given PXE-Enabled DP.

Consider this scenario: you have 2 hardware models (eg. Lenovo X1 Yoga and Lenovo X1 Carbon); you download the SCCM driver pack for both models and import them into SCCM.
When you import a driver pack you add a category to identify the model that belongs to.
After you complete the import process for both driver packs you recognize that some drivers are in use by both models.
So at the end you will have:
- drivers used by model A only
- drivers used by model B only
- drivers used by both model A and B

The main problem here is that SCCM allows you to import drivers of both driver packs but duplicated drivers are imported only once in DB; so, if you started to import driver pack of model "A" and then those of model "B", drivers used by both models will refer to the folder of driver pack of model "A", because them are imported for first.

Now the manufacturer has released a new driver pack for model "A" and you want to upgrade only these drivers. How can you achive this purpose without affecting drivers of model "B" shared by both models?

Actually, you have to:
- identify drivers used by both models
- remove the category of model "A"
- modify the source path to reflect the path of model "B"

A better and faster solution would be welcome.
Thanks

When doing a In-place upgrade and using Pre-Cache, the Task sequence process copies the needed files from Cache to _SMSTaskSequence\packages. This process can take some time when the in-place upgrade media is more than 4GB. this is unnecessary, there should be a variable to say install the OS directly from cache, or like the task sequence step to Download package content have a variable for the pre-cached source files that can then be used to access the OS later when upgrading, so that the content does not have to be copied from cache to the _SMSTaskSequence folder but rather accessed directly from the cache.

Consider the following...

You Deploy an OSD TS to a Lab and the Lab images Successfully. Next year you wish to Refresh that same Lab. You deploy this TS to the lab with the default 'Re-run Behavior' and it immediately shows as Successful because it was run before. You do another schedule and switch the 'rerun behavior' to 'Always rerun.' Lab images, grabs policy, images, grabs policy, images.........

This seems like a huge flaw to me especially for those environments that Refresh certain Labs annually (K-12, Education). I'll now have to remember each Summer to either create a new TS or copy and existing one so it has a different ID.

Current 'rerun behavior' makes sense for Packages and recurring schedules but not for OSD.