5 comments on “Adding Roles and Features During Deployment

  1. This is a good tip…except for one thing. I don’t like changing the base MDT scripts because who knows what they could change in 2013 U1 or 2014, etc.

    So what I do when I build my reference images, which is for Server 2012 R2, is to add .Net as an installed role during this build.

    In my CS.ini, I have my [Settings] to include Priority=TaskSequenceID

    Below, I have the following code block:
    WindowsSource=%DeployRoot%\Operating Systems\Windows Server 2012 R2 x64 U1\sources\sxs

    Keep in mind the part in [ ] is the name of the actual task sequence. This will point your source back at the Network Share via CustomSettings with no changes to your MDT Scripts.


  2. Thanks very much for these details. I’m doing the same thing albeit with Windows 10. Turns out the trick to avoiding the hassle of source location is to import the base OS into the MDT “with full sources” instead of using just install.wim.

    This is done with the MDT’s “Import Operating System” wizard by choosing the “Full set of source files” option and then pointing it at the contents of the Windows 10 ISO. Importing the OS in this manner avoids all the pathing issues that occur when using the role management features of the MDT.


  3. That’s great info Ryan, thanks for posting it. It makes sense too. As I noted in the article, we use SpecOps Deploy which essentially wraps around MDT, and the OS import process is therefore not something we directly see.



  4. Pingback: Installer des fonctionnalités Windows par MDT | System Management Blog

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s