Often times OSD TS fails while in WinPE (and obviously outside of WinPE) but unless the tech or user is sitting at the machine to press f8 (to bring up command prompt) the TS gives a timed windows until a reboot occurs. If my techs are not at their desk or if the imaging depots image things over night they are not there to see what failed or grab logs from PE and often times since it just reboots into windows they don't even realized the TS didn't finish. I realize not everyone would want this but it should be an option to not reboot on failure, therefore giving time for proper log collection and troubleshooting instead of duplicating effort to get the required information.

ConfigMgr 1511 CB's Service Connection Point came out of the box with a pretty cool ability to support Offline \ On-Demand updates even for those without internet access to their ConfigMgr environment through the Service Connection Tool. However for those in environments who have to content with Proxy this becomes an issue. While you can configure the site server system with proxy information that is only good for the system housing the Service Connection point, this post is requesting a change to add a switch and code base to support the switch to the Service Connection Tool to allow the use of proxy configuration as well as it is not a currently viable situation. Reference Links: https://technet.microsoft.com/en-us/library/mt691532.aspx and https://technet.microsoft.com/en-us/library/mt622757.aspx.

It would be very helpful to have a cmlet that will allow you to modify the "Run Task Sequence" with PowerShell.

I'd like to be able to script replicating an entire task sequence "suite" (including all of the nested sequences) and re-linking the new nested sequences.

My use case is something like this:
I want to start development work on a new build revision. The script would duplicate the production sequences (both parent and children) and repoint the "Run Task Sequence" steps to new "DEV" child sequences.

This would automate the process and ensure that none of the production sequences are overlooked and accidentally left in place in the development branch.

Currently, upgrading to 1602 blows away any customizations made for extending hardware inventory in configuration.mof, requiring you to manually back up the settings and restore them after the upgrade.

Make that go away, or at least less of a problem.

Some suggested solutions in order of perceived difficulty:

- Add a warning to pre-req checker if you don't have a standard configuration.mof so you know to re-implement your changes.

- Merge the changes into the customer's existing configuration.mof instead of wiping/replacing it.

- Remove the need for configuration.mof entirely - build a GUI for adding customizations, especially registry customizations

Thanks for your help!

We already get App-V for free for use with RDS, just lets just go value add with this for SCCM. It would make sooooo many people so happy.

Why can't I use the DaRT unless I have MDOP? Again: the amount of pain it saves in the mass deployment world makes it an awesome add-on.

I can see why MDOP would be a separate purchase for people who are trying to get away with just MDT ... but for those who paid for SystemCenter and are thus paying for an annual subscription ... these are all things the base SCCM should do anyway.

Stuck with adoption of 1511 blocking multiple customers from upgrading to 1511 that still have mission critical XP systems . (and yes customers are aware and customers are planning to upgrade ASAP …but it will take them a huge investment )

An example : I have a customer that is managing with CM12 r2 sp1 roughly 4000 Win7 x64 , 600 XP embedded , 2500 servers , 150 XP professional ,and 300 windows 10 clients .

They want to go to the 1511 build , but are blocked by the adaption as the 1511 client for XP Pro is not supported anymore ( read not installable) . They have SCSM in place for there CMDB (or other tooling) and they understand very well that they need to move the XP pro asap to another platform . However the move is costing them a business investment of x million Euro . That is not an IT decision to make  ) .

All they want is support from the Configmgr agent to Report on patching , inventory and be able to deploy software ( for all they care packages and programs will do ) and if possible get DCM support . That way they can use that data to control and maintain there CMDB as well .