I don't work in our AD group and I am seeking config info for Bitlocker...

We have an OU into which we can image, a policy-free OU that allows our pc's to join to our domain.
There is a separate OU for Bitlocker, which, today, we manually move a pc into and then kick off BL encryption.

I'm asking our AD group to mirror the Bitlocker policy which is on the Bitlocker OU to be the same as the policy-free OU.
My goal is to run encryption during MDT cloning.

The issue, obviously, is that we "either" place the pc in the policy-free OU in order for MDT to complete, but THEN move it to Bitlocker OU for encryption.

Is there any info I can give to our AD group to help them get the same BL policy to apply onto the policy-free OU?
All I need is to be able to encrypt in the open OU and see the key, as I can in the designated Bitlocker OU. I don't know what to tell them since I don't work in AD, but whatever it is, they can apply to a test OU for now.

Thanks

We have been using MDT to deploy windows 10 with an existing share that was configured for our needs. Today we wanted to add to our custom.ini file and we received an error message. We restarted the computer and the existing share does not show in the workbench. The files are still showing in the D: drive and have the information within them. We tried to open the share in the workbench and it won't open with the following error:

Object reference not set to an instance of an object.

System.NullReferenceException: Object reference not set to an instance of an object.
   at Microsoft.BDD.Wizards.DeploymentPointProgress.WizardProcessing()
   at Microsoft.BDD.Wizards.WizardProgress.InitiateWizardProcessing()

I have no idea how this happened and have searched for answers without success. Any and all help is appreciated

I currently image all dell computers with WDS/MDT. I currently have a TS's that does the following
1) copies files to "x:\Bios" folder
2) runs a bat file from "x:\bios" folder. Bat file script is:

::Change DIR::
cd /d x:\bios

::Flash Bios::
Flash64W.exe /b=OptiPlex7050.exe /s /f /noReboot /l=x:\bios\OptiPlex7050.log 

I have also tried just: /s /noReboot and /s /l=x:\bios\OptiPlex7050.log

The TS command line is: cmd /c x:\bios\7050.bat

I have read the logs and it shows a success code = 2 Reboot Required, however it breaks the task sequence and salmon screens resulting in an error. After the BIOS Upgrade TS runs, the next TS is a restart so the bios can finish updating and then boot back into MDT so it resume where it left off. 

I am running this on an OptiPlex7050, upgrading bios 1.11.x to 1.12.x  

The purpose of the bios being updated in the beginning is to have the CCTK tool change bios settings, such as Legacy to UEFI and other such stuff that requires the WMI ACPI bios.

 Thanks for any support.

We were hitting intermittent issues with mapping network drives during our MDT deployment sequence with the latest MDT and ADK/PE. After capturing packets and getting reliable steps to reproduce, we now know it is a bug in the currently released Windows PE, version 10.0.18362.1 .

The bug is in how the PE on the client handles a response from the server when the client uses an ephemeral port that was recently used and is half-open (server-side). An MDT task sequence can contain many reboots, leading to use of many ephemeral ports and leaving connections open only on the server side, so if you enter the PE soon after a previous sequence, this is likely to happen.

The server will respond to the client's initial SYN packet with a SYN-free ACK. The client is supposed to see this response and issue a RST. Windows 10 1803, 1903, and the associated PE environments on their install media do precisely that. But PE 10.0.18362.1 instead tries a few different ephemeral ports with increasing persistence and eventually gives up.

This bug is easy to reproduce. Set up a share on a server, and create a PE iso and a VM that boots from it. At the VM's command prompt, run

net use ***your share/credentials***
wpeutil reboot

Repeat this 5 times. By the 5th time, the net use will incur a noticeable delay. You can continue repeating until it fails. If you run packet capture software on the server side, you can see the client's incorrect behavior.

Is there any workaround for this? How can I make sure this bug is received by the appropriate team and addressed in a timely manner?

Stack overflow discussion that evolved as issue was investigated

I set up a couple of new Server 2016 servers and a new Windows domain. I don't want to upgrade the existing domain since it's already upgraded a couple of times, and the domain name is incorrect. So that's all fixed with the new servers and new domain. As a result, the client PC's, mostly Windows 10, have to switch to the new domain. No problem. Same for the users. Ah - a new domain means a new user profile. Okay for those who like a fresh start. But for those who want to keep their current profile, I'm trying to export / import those with USMT. Since I would like to 'migrate' ALL settings, I created a XML file like this:

<?xml version="1.0" encoding="UTF-8"?><migration urlid="http://www.microsoft.com/migration/1.0/migxmlext/migautodesk"><component type="System" context="User"><displayName _locID="miguser.everything">everything</displayName><role role="Settings"><detects><detect><condition>MigXmlHelper.DoesObjectExist("File","%CSIDL_APPDATA%")</condition></detect></detects><rules><include filter="MigXmlHelper.IgnoreIrrelevantLinks()"><objectSet><pattern type="File">%CSIDL_APPDATA%\* [*]</pattern><pattern type="Registry">HKCU\SOFTWARE\ [*]</pattern></objectSet></include><locationModify script="MigXmlHelper.RelativeMove('%CSIDL_APPDATA%','%CSIDL_LOCAL_APPDATA%')"><objectSet><pattern type="File">%CSIDL_APPDATA%\* [*]</pattern></objectSet></locationModify></rules></role></component></migration>

The command line:

scanstate /i:everything.xml /l:scanstate_%computername%.log \\server\d$\mystore /ue:*\* /ui:domain\user /o /localonly

No errors exporting and importing. 

This works partially - not all settings are exported / imported. I also notice a bunch of folders located in the original user profile underRoaming appdata now appear under Local appdata in the target folder.

I take it my approach is way too simple to work, so I wonder what to do to migrate all user settings from domain X to domain Y?

Simon Weel

Hi, I've run into a problem trying to boot into and MDT environment to perform an initial syprep and capture. after starting the VM I'm using it sits there for maybe a minute then goes to a command prompt, the only error i have been able to find is in wpeinit.log where the following two lines are logged

2019-05-02 20:02:56.384, Info      Successfully executed command 'wscript.exe X:\Deploy\Scripts\LiteTouch.wsf' (exit code 0x00001577)

2019-05-02 20:02:56.384, Info      STATUS: FAILURE (0x80071577)

then the final line

2019-05-02 20:02:56.384, Warning   Applying WinPE unattend settings failed with status 0x80071577; ignoring shutdown settings

I can't find anything on any of these error codes.

I have tried updating the deployment share and have even gone as far as to create a new deployment server VM, install the ADK and MDT on that and try again with the same results. exploring the deployment VM shows that the scripts exists in the correct place and it can connect to the deployment server.

Any help would be greatly appreciated.

Hi Team,

Please help to understand the below

1. What are the benefits of integrating MDT with SCCM

2. How does Roles in MDT  recognized during the OSD in a computer using SCCM

3. How does the applications in the MDT roles called during the OSD in a computer using SCCM

 4. If MDT and SCCM integrated then How can a new computer added to the OSD collection, also how does it starts the OSD when boot from network or USB Stick

Regards, Boopathi

I have Bitlocker encryption enabled during MDT. The recovery password is stored correctly to our AD.

However, looking at the target pc, the recovery key is in plain sight in a text file on C:

I guess I do not fully understand the difference between the two. If a user needs a recovery password, we go to AD and give them the Bitlocker Recovery password.

I do not want a key stored on the pc. I don't need it stored anywhere but in AD.
So, how can I stop the key from being written to anywhere but AD?

Hello

Is this a normal behavior that MDT writes the key to c:\ drive into a text file ?

thanks

The media deployment point WIM splitting functionality does not seem to be working in MDT 2013 Update 2. Although I have been unable to find official documentation or guidance on the functionality, I have gathered from various posts here and elsewhere that these are the requirements:

1. SkipWIMSplit should be set to "False" in Settings.xml
2. The operating system (WIM) and corresponding deployment task sequence should be included in the selection profile used for the media deployment point
3. The operating system (WIM) should be 4GB+ in size

All of these requirements have been met in my environment but when I update media, the 10GB WIM is not recognized as 4GB+ and is not split. I have prepared a "vanilla" environment (Server 2012 R2, WAIK 1511, MDT 2013 Update 2, zero customizations or changes to defaults) to work on this issue but still no success.

Anyone out there have this working? If so, what have you implemented in addition to the three items above.

Finally, where is the documentation for this?

Thanks in advance for any help or guidance. 

Hi,

I have setup a Win2008R2 Server with MDT2010 Upd1.

Multicats is enabled in properties for the Deployment share and the bootimage is updated and imported into WDS.

Issue arrises when we do the deployment and the task reaches the install operating system. It says attempting multicats, which I think is normal, but the download of the custom image is veeery slow. Image is apprx. 4.7 GB. Download is only happening in chunks of 1-2 MB but with 10-15 secs intervals.

I can see in the WDS console that the Multicast session is established fine but status says waiting. Also the network utilization says only 1% in there. If I right click on the multicast session in WDS and click on Bypass Multicast the installation continues fine and finishes up quickly by running the installation directly deom the deployment share.

I have looked in the LTIApply_wdsmcast.log file, but there is no useable information.

I have the same setup running in a virtual testenvironment, where it runns fine.

Any hints how to troubleshoot this is much appreciated.

Thanks

Thomas

Hi All,

Working through a Windows 10 deployment scenario using WDT and WDS using the following as a guide:

Deploy a Windows 10 image using MDT

This was working a few months ago and I had to leave it for another task. I have just picked it up again and noticed that after the deployment splash screen starts I get a network credentials prompt, populated with the username and the domain name.

All the credentials are in the customsettings.ini and I notice that even if I type the credentials in the prompt they fail.

I have checked for logs but nothing, recreated the deployment share, task sequence and boot images but get the same message.

Any suggestions on where to look next would be greatly appreciated!

Thanks in advance,

Matt

I have been trying to deploy the image but keeps failing without any errors in the logs, could anyone point me in the right direction to see where I may be going wrong.

Below are the logs.

<![LOG[Not Wizard = False]LOG]!><time="02:46:41.000+000" date="09-09-2019" component="Wizard" context="" type="1" thread="" file="Wizard"> <![LOG[Property WizardComplete is now = N]LOG]!><time="02:46:41.000+000" date="09-09-2019" component="Wizard" context="" type="1" thread="" file="Wizard"><![LOG[          Open Control File: TaskSequences]LOG]!><time="02:46:42.000+000" date="09-09-2019" component="Wizard" context="" type="1" thread="" file="Wizard"> <![LOG[Property TaskSequenceID is now = ABM]LOG]!><time="02:47:04.000+000" date="09-09-2019" component="Wizard" context="" type="1" thread="" file="Wizard"><![LOG[Found Task Sequence Item: //step[@type='BDD_InstallOS']]LOG]!><time="02:47:04.000+000" date="09-09-2019" component="Wizard" context="" type="1" thread="" file="Wizard"><![LOG[Found Task Sequence step of type //step[@type='BDD_InstallOS'] = True]LOG]!><time="02:47:04.000+000" date="09-09-2019" component="Wizard" context="" type="1" thread="" file="Wizard"><![LOG[Found Task Sequence Item: //step[@type='BDD_UpgradeOS']]LOG]!><time="02:47:04.000+000" date="09-09-2019" component="Wizard" context="" type="1" thread="" file="Wizard"><![LOG[Found Task Sequence step of type //step[@type='BDD_UpgradeOS'] = ]LOG]!><time="02:47:05.000+000" date="09-09-2019" component="Wizard" context="" type="1" thread="" file="Wizard"><![LOG[DeploymentType = NEWCOMPUTER]LOG]!><time="02:47:05.000+000" date="09-09-2019" component="Wizard" context="" type="1" thread="" file="Wizard"> <![LOG[Property DeploymentType is now = NEWCOMPUTER]LOG]!><time="02:47:05.000+000" date="09-09-2019" component="Wizard" context="" type="1" thread="" file="Wizard"> <![LOG[NON-OS Upgrade Task Sequence is selected, setting Environment var IsOSUpgrade = 0]LOG]!><time="02:47:05.000+000" date="09-09-2019" component="Wizard" context="" type="1" thread="" file="Wizard"> <![LOG[Property IsOSUpgrade is now = 0]LOG]!><time="02:47:05.000+000" date="09-09-2019" component="Wizard" context="" type="1" thread="" file="Wizard"> <![LOG[Property ImageProcessor is now = ]LOG]!><time="02:47:05.000+000" date="09-09-2019" component="Wizard" context="" type="1" thread="" file="Wizard"> <![LOG[Property OSGUID is now = ]LOG]!><time="02:47:05.000+000" date="09-09-2019" component="Wizard" context="" type="1" thread="" file="Wizard"> <![LOG[Property TaskSequenceName is now = Surface Pro]LOG]!><time="02:47:05.000+000" date="09-09-2019" component="Wizard" context="" type="1" thread="" file="Wizard"> <![LOG[Property TaskSequenceVersion is now = 1.0]LOG]!><time="02:47:05.000+000" date="09-09-2019" component="Wizard" context="" type="1" thread="" file="Wizard"> <![LOG[Property TaskSequenceTemplate is now = Client.xml]LOG]!><time="02:47:05.000+000" date="09-09-2019" component="Wizard" context="" type="1" thread="" file="Wizard"> <![LOG[Property IsOSUpgrade is now = ]LOG]!><time="02:47:05.000+000" date="09-09-2019" component="Wizard" context="" type="1" thread="" file="Wizard"> <![LOG[Property DeploymentType is now = NEWCOMPUTER]LOG]!><time="02:47:05.000+000" date="09-09-2019" component="Wizard" context="" type="1" thread="" file="Wizard"> <![LOG[Property IsOSUpgrade is now = 0]LOG]!><time="02:47:05.000+000" date="09-09-2019" component="Wizard" context="" type="1" thread="" file="Wizard"> <![LOG[Property OSGUID is now = {b6e79bcd-1057-4bd0-b7d8-dcfd1bd7ba99}]LOG]!><time="02:47:06.000+000" date="09-09-2019" component="Wizard" context="" type="1" thread="" file="Wizard"> <![LOG[Property ImageIndex is now = 3]LOG]!><time="02:47:06.000+000" date="09-09-2019" component="Wizard" context="" type="1" thread="" file="Wizard"><![LOG[Property ImageSize is now = 13929]LOG]!><time="02:47:06.000+000" date="09-09-2019" component="Wizard" context="" type="1" thread="" file="Wizard"> <![LOG[Property ImageFlags is now = Enterprise]LOG]!><time="02:47:06.000+000" date="09-09-2019" component="Wizard" context="" type="1" thread="" file="Wizard"> <![LOG[Property ImageBuild is now = 10.0.17763.107]LOG]!><time="02:47:06.000+000" date="09-09-2019" component="Wizard" context="" type="1" thread="" file="Wizard"> <![LOG[Property ImageProcessor is now = x64]LOG]!><time="02:47:06.000+000" date="09-09-2019" component="Wizard" context="" type="1" thread="" file="Wizard"> <![LOG[Property ImageLanguage001 is now = en-US]LOG]!><time="02:47:06.000+000" date="09-09-2019" component="Wizard" context="" type="1" thread="" file="Wizard"> <![LOG[InstallFromPath: \\LONMDT01V\DeploymentShare$\Operating Systems\Windows 10 Professional v1809\Sources\install.wim]LOG]!><time="02:47:06.000+000" date="09-09-2019" component="Wizard" context="" type="1" thread="" file="Wizard">

If I manually run Bitlocker on a pc on the domain, a recovery password gets written to AD in the properties of that pc.

IF I run BL through MDT, the same...a recovery password is written to AD.
However, through MDT I see a text file get written to C: which contains the "key". Looking at the data, it is exactly the same as the recovery "password" in AD.

My question is, how do I NOT save a local copy of that key/password? Right now I have a final step in all of my TS's which is

cmd /c del C:*.txt

that deletes the text containing the key. What's the proper way to deal with this?
Thanks

I am testing new boot image from MDT 8456

the image is placed on PXE (WDS).

On older model everything is fine. The WINPE loads, I login and can select and deploy W10 image.

On new Dell Laptop the right wim is loaded, I see nice grey screen with MDT logo but instead of Lite Touch screen it brings CMD with windows\system32 prompt.

What it could be?

Thx.

--- When you hit a wrong note its the next note that makes it good or bad. --- Miles Davis

I have an old Dell T410 server with limited storage. My division has a new T440 that I can use as a new MDT server.

The old one has Server2012 where the new one will have 2016.

They are thinking that just manually copying folders over from one to the other will get me going, but I know step 1 will be installing MDT. Then, I won't have any Deploy Shares at all, or driver structures.

Am I looking at having to rebuild my entire MDT? That would seem like a nightmare with all of the minute steps and conditions and exceptions.....

What's the easiest method to get a new MDT server going if upgrading models of the server?

Running MDT 8456, ADK 1903, and Windows PE Add-on 1903

Deploying Windows 10 LTSC 2019

After deploying the image all Junction Points still exist, however, they are begin with D:\

What cause this and how do I fix it?

The issue I am running into seems quite random.  We can rebuild dozens computers, with out an issue.  But sometimes when we build a new one computer we have issues.

The initial MDT build is smooth and with out issues, but after the restart one of two things randomly occurs.   

1 - The task sequence never starts, even with multiple restarts.  - Rerunning the MDT imaging gets it started back up, or some times plugging it into a different network drop across the hall.

2 - The task sequence starts up, but fails when pulling data from the MDT server.  Which means the scripts just hang.  The computer has an IP and can hit Microsoft.com to download office 365 with the office deployment tool, but not install anything from MDT\Applications.

My network team tells me there is no problems on there end, any ideas?