I've created a new issue for myself.  After testing the Windows Security Baseline GPO's on many test systems, I applied them to authenticated users.  No user complaints so far, but my MDT deployments seem to have been affected.

I first noticed first that the Windows 10 deployments were rebooting then not logging on automatically, prompting that the password was incorrect.  I supplied passwords manually after reboot to let the task sequence continue.

Then they would just stop without an error.  Checking the OSD logs (locally, were not in the server logs directory), there was nothing indicating a problem.  They just seem to stop after joining the domain and rebooting.

I excluded a few test machines from these new GPO's and they completed successfully without any problems.  I was able to track it down to a single set of GPOs.

Any idea which of these policies from the WSB 1511 T2 could be causing this?

OneDrive Link to Settings Report PDF

https://1drv.ms/b/s!AiN4S4MKpH5AkmPU1WfbqK9RQEZo

(Irrelevant and audit settings collapsed in report)

Thanks,

-Matt

There's no place like 127.0.0.1

Hi all,

I do admit I am in a learning phase concerning MDT 2013 U2, so please bear with me on this probably simple issue.

Whenever I build a fresh Windows 7 x64 and insert a "Restart Computer" task sequence, it does reboot, but it always start up with a blank Litetouch wizard window and never resumes. This has been tested on a virtual PC as well as physical. Also with and without drivers. In fact I just tried to deploy a vanilla Windows 7 x64 with just that Restart Computer step added in State Restore and it fails too. Disk 0 is cleaned at every test. Network card is OK and access to Deployroot is fine too after the restart.

If needed I've uploaded the recent smsts.log here: SMSTS.log

Also a screenshot that shows that the Wizard.hta is trying to run from a local folder (C:\Users\...\Temp\DeploymentScripts\Wizard.hta), but that folder is empty:

In BDD.log it also seem to have trouble resuming:

About to run command: "C:\MININT\Tools\X64\TsmBootstrap.exe" /env:SAContinue	LiteTouch	14-06-2016 15:19:44	0 (0x0000)
Property LTIDirty is now = TRUE	LiteTouch	14-06-2016 15:19:44	0 (0x0000)
Command completed, return code = -2147467259	LiteTouch	14-06-2016 15:19:45	0 (0x0000)
Litetouch deployment failed, Return Code = -2147467259  0x80004005	LiteTouch	14-06-2016 15:19:45	0 (0x0000)
Event 41014 sent: Litetouch deployment failed, Return Code = -2147467259  0x80004005	LiteTouch	14-06-2016 15:19:45	0 (0x0000)

Has anybody sysprep a computer that has more that one hard drive? Drive 0 had the OS on it and the second drive has most of the programs on it. To add to the issue drive 0 is a SSD. In the page imaging a computer with a SSD as the primary drive was not possible.   I'm running MDt 2013 update 1. I haven't started researching so if someone has some information on how this can be done please let me know

thanks.

Kris Da San Martino

Orange County District Attorney

I have MDT installed and have images built. My ip for mdt is 152.146.74.135

when i boot a system for a pxe boot it does not pull an ip address even though this is configured in dhcp

if i place the system onto a different dhcp server i do get a dhcp address.

what needs to be configured to allow me to see across subnets if i cant pull an ip address on the .74 range? i get an ip on a .54 address range.

Hello,

I am using MDT to deploy a Windows 10 image to a test device. After the imaging process the machine logs into the Administrator account where usually the Deployment Wizard should launch and complete the MDT deployment, following a successful message or errors. However, after the device auto logs into the Administrator account to complete MDT, I am presented with a blank Wizard.hta screen. I followed the path to where the Wizard.hta is launching from and the folder is empty.

Folder = C:\Users\ADMINI~1\AppData\Local\Temp\DeploymentScripts\Wizard.hta

I also located the log file and found this: (Wizard.log)

<![LOG[Property LogPath is now = C:\MININT\SMSOSD\OSDLOGS]LOG]!><time="15:39:25.000+000" date="03-14-2016" component="Wizard" context="" type="1" thread="" file="Wizard"><![LOG[Microsoft Deployment Toolkit version: 6.3.8330.1000]LOG]!><time="15:39:25.000+000" date="03-14-2016" component="Wizard" context="" type="1" thread="" file="Wizard"><![LOG[Property Debug is now = FALSE]LOG]!><time="15:39:25.000+000" date="03-14-2016" component="Wizard" context="" type="1" thread="" file="Wizard"><![LOG[Not Wizard = False]LOG]!><time="15:39:25.000+000" date="03-14-2016" component="Wizard" context="" type="1" thread="" file="Wizard"><![LOG[FAILURE ( 20001 ): Definition file not defined. Please call with /Defintion:<file>   CommandLine:"\\myimages\mymdt\Scripts\Wizard.hta"]LOG]!><time="15:39:25.000+000" date="03-14-2016" component="Wizard" context="" type="3" thread="" file="Wizard"><![LOG[Microsoft Deployment Toolkit version: 6.3.8330.1000]LOG]!><time="15:40:01.000+000" date="03-14-2016" component="Wizard" context="" type="1" thread="" file="Wizard"><![LOG[Not Wizard = False]LOG]!><time="15:40:01.000+000" date="03-14-2016" component="Wizard" context="" type="1" thread="" file="Wizard"><![LOG[FAILURE ( 20001 ): Definition file not defined. Please call with /Defintion:<file>   CommandLine:"\\myimages\mymdt\Scripts\Wizard.hta"]LOG]!><time="15:40:01.000+000" date="03-14-2016" component="Wizard" context="" type="3" thread="" file="Wizard">

Would anyone know why the Wizard.hta is not properly launching and why MDT is not completing on Windows 10? 

Thank-you,

AP

Hello all

I am running a Windows 10 ZTI install using SCCM 2012 R2 Sp1 CU3. Image captured using MDT 2013 Update 2.

Deploying to a Hyper-V 2012 R2 VM.

Very weird issue. Deployment kicks off fine, past the point of WIM application to the OSD Install phase.

The machine comes up, and basically at the point of ZTIConfigure, im getting an error in the specialize pass.

 Windows could not parse or process the unattend answer file for pass [specialize]. The settings specified in the answer file cannot be applied. The error was detected while processing settings for component [Microsoft-Windows-Shell-Setup].

This is from my setuperr.log in unattendgc

2016-06-11 12:14:48, Error                        [Shell Unattend] ComputerName: failed to set the computer name [hr=0x80070057][gle=0x00000057]
2016-06-11 12:37:28, Error                        [windeploy.exe] Setup.exe failed, returning exit code [0x1f]
2016-06-11 12:37:28, Error                        [windeploy.exe] Failure occured during online installation.  Online installation cannot complete at this time.; hr = 0x80004005

From my Setupact.log  below from unattendgc:

Excerpt from my setupact.log from unattend showing architecture.

My Unattend.xml excerpt is below. I have taken this from the failed build. Notice that the computername below under the am64 section is specialize is set correctly. However the build fails. The following x86 computername field highlighted is currently blank when the build fails. But if I edit the x86 field slightly furher down in specialize as highlighted  (before the install phase starts via f8 command prompt), the build succeeds.

Why would it parse the x86 section as well for a computer name? I am using a standard MDT install, Windows 10 64bit install. And if it parses it anyway, why is it failing as it has already populated the AMD64 section. 

The OSDCOmputername is retrieved from SCCM in a pre imported object in a build collection.

Any help appreciated, really don't understand why its doing this - could it be something with using Hyper-V?

Thanks

Ian

Hi All,

I've built an offline Media stick that i can take to my client sites and build their PC's offline, but due to our security policy i cant take any private data out of our main office unless its encrypted. This means my offline stick cant contain domain, OU, admin accounts, product keys etc. obviously i cant just use bitlocker GO like i do on my other external disk and USBs.

So my question is, is it possible to secure or encrypt the data on an offline media USB?

Thank in advance

Rob

Hello hoping someone can point me in the right direction.

I have MDT 2013 on Windows 2008 Server and have updated to the latest patch etc. but I can't seem to figure out AHCI when deploying Windows 7. The machines image correctly but after the OS has been deployed and the machine reboots to boot into the new OS for the first time it blue screens.

Basically all the machines we have had to date have had the issue but they have always imaged successfully if you set them to IDE/Compatible mode in the BIOS. However, we've had a couple of new Panasonic and Dells in that no longer have an IDE option in the BIOS so I have to have them set to AHCI.

Now I know people are going to immediately say "make sure your storage drivers are being injected" and I know they are. What I did discover however, is that if I remove them from the driver store in MDT and DONT inject them the images boot up fine with the default Microsoft AHCI driver. Once booted I can manually install the AHCI driver from the manufacturer without an issue and everything is stable.

So why when I try to inject the manufacturers driver do I get a blue screen but when I don't inject one at all and the default MS one is used does it work?

Any ideas???

Many Thanks

Hi all,

Been having an issue with our Surface Pro 3 and Windows 10 ever since MDT 2013 Update 2 was installed a few weeks ago (might just be a coincidence). 

No matter what I do, our custom desktop wallpaper is not being applied during the deployment. Instead, we'll be greeted with a solid black background, not even the default Hero Win10 wallpaper.

Before Windows 10, we used to have a task in our Task Sequence called "Copy OEM Folder", which would copy our custom "img0.jpg" file from our Deployment Share to the right path (%windir%\Web\Wallpaper\Windows) while the OS was still offline. This worked fine, until Windows 10, where it would just show a solid black background instead of our company wallpaper.

I tried many things back then, with no success. I ended up setting our company wallpaper as the background for the Administrator image of our custom image, which would then be copied over to every new user account on the computer through the "CopyProfile" function in the TS's Unattend.xml file. 

This worked fine, until I created a new Win10 custom image from scratch and upgraded to MDT 2013 Update 2, and am now back to square one.

Even though my captured image's Administrator account has our custom wallpaper set as background, the new profiles only have a solid black background. Note that this issue only happens with Surface Pro 3 tablets. If I take the image and deploy it to a VM or a desktop computer, it works fine.

I have tried many things: 

1. Re-enabling the "Copy OEM Folder" task in our TS: The file gets copied and replaces the default Hero wallpaper, yet the OS does not seem to recognize it as I am greeted with a black wallpaper. If I open the personalize menu, I see my custom wallpaper as the first and default one...if I click on it, then it works, but just for the current user.
2. I read somewhere that by default, Windows 10 searches in "%windir%\Web\4K\Wallpaper\Windows" for an image file with the appropriate resolution (img0_2160x1440.jpg). I have thus taken our custom wallpaper, resized it to 2160x1440 (the default Surface Pro 3, named it "img0_2160.1440.jpg", made sure the size was small enough (40kb), and made sure it was deployed to the right path with our "Copy OEM folder" task: Nothing, still a solid black background.
3. Tried #2 but I used different resolutions (aka, I replaced all the current wallpapers at "%windir%\Web\4K\Wallpaper\Windows" with our custom wallpaper, resized and renamed to all the resolutions in the folder) : Did not work
4. Read on the web some guy was simply deleting and/or renaming the "%windir%\Web\4K\Wallpaper\Windows" folder to prevent Windows from looking into it: Did not work.
5. In the Unattend.xml answer sheet, you can set your desktop background through the "DesktopBackground" settings in "7 oobeSystem > amd64_Microsoft-Windows-Shell-Setup_neutral > Themes". I copied our desktop wallpaper, "sidlee_background_big.jpg" to "%windir%\System32" folder, and set the DesktopBackground setting to "%windir%\System32\sidlee_background_big.jpg": Did not work, still a solid black background.

Am I missing something here ? Some different access rights necessary for Windows 10 ?

We want to avoid having to go the manual way of setting the wallpaper for each user OR having to set it up using a GPO, because we want our branding there yet not prevent the user from changing it themselves.

Thanks in advance!

I'm not sure when this problem started but now every time I capture an image the local admin account is disabled.  I have made the changes in the unattend.xml that should re-enable the local admin account and this has worked in the past. I have updated to the latest ADK 1511 and MDT 2013 u2.

I have compared a machine that was deployed previously to the current reference image and noticed that there were missing sections in the unattend.xml after booting notably the auto login portion. I have copied the portion of the Unatted files below.

Is this causing my issue? if so how can I fix this? or am looking completely in the wrong place?

Thanks,

"Working one"

 <settings pass="oobeSystem" wasPassProcessed="true">
  <component name="Microsoft-Windows-Shell-Setup" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm=http://schemas.microsoft.com/WMIConfig/2002/State>
   <UserAccounts>
    <AdministratorPassword>*SENSITIVE*DATA*DELETED*</AdministratorPassword>
   </UserAccounts>
   <AutoLogon>
    <Enabled>true</Enabled>
    <Username>Administrator</Username>
    <Domain>.</Domain>
    <Password>*SENSITIVE*DATA*DELETED*</Password>
    <LogonCount>999</LogonCount>
   </AutoLogon>
   <Display>
    <ColorDepth>32</ColorDepth>
    <HorizontalResolution>1</HorizontalResolution>
    <RefreshRate>60</RefreshRate>
    <VerticalResolution>1</VerticalResolution>
   </Display>

"Broken One"

 <settings pass="oobeSystem" wasPassProcessed="true">
  <component name="Microsoft-Windows-Shell-Setup" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm=http://schemas.microsoft.com/WMIConfig/2002/State>
   <UserAccounts>
    <AdministratorPassword>*SENSITIVE*DATA*DELETED*</AdministratorPassword>
   </UserAccounts>
   <Display>
    <ColorDepth>32</ColorDepth>
    <HorizontalResolution>1</HorizontalResolution>
    <RefreshRate>60</RefreshRate>
    <VerticalResolution>1</VerticalResolution>
    <DPI>480</DPI>
   </Display>

I've tried to do as much research as I can on this but any answers to any similar questions haven't worked for me. I'm trying to deploy Windows 7 x64. I have an image that works perfectly, but had an unwanted account on it and wasn't quite up to date. I installed that image, updated and removed the unwanted account, and recaptured the image (manually, the mdt capture sequence wasn't working).

When trying to deploy the new image it stops the task sequence on the first reboot. It successfully installs the OS and gets through Copy Scripts, Configure, Inject Drivers, and Add Windows Recovery in the Postinstall section. My bdd.log says that ZTINextPhase processing completed successfully, then stops. The client boots to a Windows login screen (with no valid logins as it never joined the domain or enabled local admin). I can continue the sequence by booting to WinPE again and selecting "no" when it asks if I want to ignore the "in progress" deployment, but I have to do this for every restart in the task sequence.

Here's the last few lines of the bdd.log:

<![LOG[Updated C:\MININT\Unattend.xml with DestinationDisk=0 (value was 0)]LOG]!><time="07:06:45.000+000" date="06-16-2016" component="ZTIConfigure" context="" type="1" thread="" file="ZTIConfigure">
<![LOG[Updated C:\MININT\Unattend.xml with DestinationPartition=3 (value was 3)]LOG]!><time="07:06:45.000+000" date="06-16-2016" component="ZTIConfigure" context="" type="1" thread="" file="ZTIConfigure">
<![LOG[Rewrote C:\MININT\Unattend.xml with changes]LOG]!><time="07:06:45.000+000" date="06-16-2016" component="ZTIConfigure" context="" type="1" thread="" file="ZTIConfigure">
<![LOG[ZTIConfigure COMPLETED.  Return Value = 0]LOG]!><time="07:06:45.000+000" date="06-16-2016" component="ZTIConfigure" context="" type="1" thread="" file="ZTIConfigure">
<![LOG[ZTIConfigure processing completed successfully.]LOG]!><time="07:06:45.000+000" date="06-16-2016" component="ZTIConfigure" context="" type="1" thread="" file="ZTIConfigure">
<![LOG[Event 41001 sent: ZTIConfigure processing completed successfully.]LOG]!><time="07:06:46.000+000" date="06-16-2016" component="ZTIConfigure" context="" type="1" thread="" file="ZTIConfigure">
<![LOG[Processing drivers for an X64 operating system.]LOG]!><time="07:06:46.000+000" date="06-16-2016" component="ZTIdrivers" context="" type="1" thread="" file="ZTIdrivers">
<![LOG[OSDTargetDriveCache was determined earlier : C:]LOG]!><time="07:06:46.000+000" date="06-16-2016" component="ZTIdrivers" context="" type="1" thread="" file="ZTIdrivers">
<![LOG[Property OSDTargetDriveCache is now = C:]LOG]!><time="07:06:46.000+000" date="06-16-2016" component="ZTIdrivers" context="" type="1" thread="" file="ZTIdrivers">
<![LOG[Property OSDisk is now = C:]LOG]!><time="07:06:46.000+000" date="06-16-2016" component="ZTIdrivers" context="" type="1" thread="" file="ZTIdrivers">
<![LOG[No driver copying needs to be performed during the Lite Touch postinstall phase.]LOG]!><time="07:06:46.000+000" date="06-16-2016" component="ZTIdrivers" context="" type="1" thread="" file="ZTIdrivers">
<![LOG[Updating downlevel OS configuration.]LOG]!><time="07:06:46.000+000" date="06-16-2016" component="ZTIdrivers" context="" type="1" thread="" file="ZTIdrivers">
<![LOG[Vista identified, skipping update of Device Path]LOG]!><time="07:06:46.000+000" date="06-16-2016" component="ZTIdrivers" context="" type="1" thread="" file="ZTIdrivers">
<![LOG[ZTIdrivers processing completed successfully.]LOG]!><time="07:06:46.000+000" date="06-16-2016" component="ZTIdrivers" context="" type="1" thread="" file="ZTIdrivers">
<![LOG[Event 41001 sent: ZTIdrivers processing completed successfully.]LOG]!><time="07:06:46.000+000" date="06-16-2016" component="ZTIdrivers" context="" type="1" thread="" file="ZTIdrivers">
<![LOG[Will boot into Windows PE architecture x64 to match OS being deployed.]LOG]!><time="07:06:47.000+000" date="06-16-2016" component="ZTIWinRE" context="" type="1" thread="" file="ZTIWinRE">
<![LOG[OSDTargetDriveCache was determined earlier : C:]LOG]!><time="07:06:47.000+000" date="06-16-2016" component="ZTIWinRE" context="" type="1" thread="" file="ZTIWinRE">
<![LOG[Property OSDTargetDriveCache is now = C:]LOG]!><time="07:06:47.000+000" date="06-16-2016" component="ZTIWinRE" context="" type="1" thread="" file="ZTIWinRE">
<![LOG[Property OSDisk is now = C:]LOG]!><time="07:06:47.000+000" date="06-16-2016" component="ZTIWinRE" context="" type="1" thread="" file="ZTIWinRE">
<![LOG[WinRE is not enabled, Skip.]LOG]!><time="07:06:47.000+000" date="06-16-2016" component="ZTIWinRE" context="" type="1" thread="" file="ZTIWinRE">
<![LOG[ZTIWinRE processing completed successfully.]LOG]!><time="07:06:47.000+000" date="06-16-2016" component="ZTIWinRE" context="" type="1" thread="" file="ZTIWinRE">
<![LOG[Event 41001 sent: ZTIWinRE processing completed successfully.]LOG]!><time="07:06:47.000+000" date="06-16-2016" component="ZTIWinRE" context="" type="1" thread="" file="ZTIWinRE">
<![LOG[Property PHASE is now = STATERESTORE]LOG]!><time="07:06:47.000+000" date="06-16-2016" component="ZTINextPhase" context="" type="1" thread="" file="ZTINextPhase">
<![LOG[ZTINextPhase COMPLETED.  Return Value = 0]LOG]!><time="07:06:47.000+000" date="06-16-2016" component="ZTINextPhase" context="" type="1" thread="" file="ZTINextPhase">
<![LOG[ZTINextPhase processing completed successfully.]LOG]!><time="07:06:47.000+000" date="06-16-2016" component="ZTINextPhase" context="" type="1" thread="" file="ZTINextPhase">
<![LOG[Event 41001 sent: ZTINextPhase processing completed successfully.]LOG]!><time="07:06:47.000+000" date="06-16-2016" component="ZTINextPhase" context="" type="1" thread="" file="ZTINextPhase">

Bit extra information, I'm using MDT 2012 and have tried the deployment from two different deployment shares, remade the task sequence, and recaptured the image too many times to count. I can't think of a reason for it to stop, and the log isn't helpful. Any ideas?

During my MDT 2013 task sequence, I have a step to install the SCCM 2012 R2 client.  During this task something causes a new deployment to attempt to kick-off, which generates a "Dirty Environment Found" message and ends the task sequence.

In my searching I found this thread, which appears to be the same issue:

https://social.technet.microsoft.com/Forums/en-US/4cc1c6a0-8651-4c40-a035-48b47692bb97/ccmsetup-during-lti-causes-dirty-environment?forum=mdt

The only recommendation out of that thread was to install the SCCM client through other means.  Unfortunately, the SCCM environment is managed by another team and we don't have the option of deploying using the recommended methods (as much as I'd like to).  Are there any other options or modifications I can make to my ccmsetup task sequence to prevent this issue?

I have been successfully updating our corporate Windows 10 Ent image with Windows Updates and then capturing the .wim until this week.  My process has been to deploy our current base image (no apps installed) via MDT to a Hyper-V VM, run Windows Updates, then run Sysprep and Capture to create an updated .wim.  As of this week, after updating the VM, the S&C TS will stall after attempting to run the Sysprep step, then the VM reboots and returns to the Windows OS that has been updated.

This only happens after running Windows Updates.  As a test, I ran the S&C TS immediately after deploying the base .wim to a VM, and it ran flawlessly.

I have not changed any of my TS's and the S&C TS is not customized in any way.  I'm using MDT 2013 Update 1.

Any help or insight on this would be greatly appreciated.  Thanks in advance.

We just upgraded our MDT server to Update 2.  After the update, monitoring is not longer working.  The service is running and the settings in cs.ini are correct.  The bdd.log on the client shows an error from the web service - "Unexpected response from web service: 400 Bad Request"

The monitoring service was working perfectly before upgrading to Update 2.  Has anyone seen this issue?

During loadstate, I'd like to have USMT move all .LNK's on the Desktop into a separate directory; leaving no .LNK files on the desktop.

The XML below will put .LNK files in the specified directory, but it will curiously also leave all the .LNK files on the desktop.  (So I'm left with 2 copies of each .LNK: one in the specified directory & one on the desktop).

<!-- This component migrates Desktop files --><component type="Documents" context="User"><displayName _locID="miguser.desktop">Desktop</displayName><paths><path type="File">%CSIDL_DESKTOP%</path></paths><role role="Settings"><detects><detect><condition>MigXmlHelper.DoesObjectExist("File","%CSIDL_DESKTOP%")</condition></detect></detects><rules><include filter='MigXmlHelper.IgnoreIrrelevantLinks()'><objectSet><pattern type="File">%CSIDL_DESKTOP%\* [*]</pattern></objectSet></include><!-- Move .LNK files --><locationModify script="MigXmlHelper.Move('%CSIDL_DESKTOP%\Old_Shortcuts_1')"><objectSet><pattern type="File">%CSIDL_DESKTOP% [*.lnk]</pattern><pattern type="File">%CSIDL_DESKTOP%\* [*.lnk]</pattern></objectSet></locationModify><merge script="MigXmlHelper.DestinationPriority()"><objectSet><pattern type="File">%CSIDL_DESKTOP% [desktop.ini]</pattern><pattern type="File">%CSIDL_DESKTOP%\* [*]</pattern></objectSet></merge></rules></role></component>

Hoping someone can someone help me better understand what's missing/wrong.

Using USMT 10[.0.10586.0]; Source machine Win 7; Destination Win 10.

Diego Cáceres | IT Solutions Consultant |

With the exception of two make & models, all machines will get the same Task Sequence.  I was trying to customize the CS.ini for those two system types (focusing on one at a time until I was confident I had it working right) and in doing that I broke something.  Now when I run cscript //nologo D:\DeploymentShare\Scripts\ZTIGather.wsf /debug:true It seems to run fine up to a point then errors out: 

PS H:\> cscript //nologo D:\DeploymentShare\Scripts\ZTIGather.wsf /debug:true
'debug' parameter was specified.
Property debug is now = TRUE
Microsoft Deployment Toolkit version: 6.0.2223.0
------------------------- Object Initialization -------------------------
SUCCESS: 0: Create object: Set oScriptClass = New ZTIGather
------------------------- Initialization -------------------------
Update progress [ 1 ] : Initializing.
Synchronizing the environments.
Finished synchronizing the environments.
Update progress [ 10 ] : Getting local computer information: Operating system
Getting OS info
Property OSCurrentVersion is now = 6.1.7601
Property OSCurrentBuild is now = 7601
Property OSVersion is now = 2008R2
Property IsServerOS is now = True
Property IsServerCoreOS is now = False
Finished getting OS info
SUCCESS: 0: GetOSVersion for Gather process
Update progress [ 15 ] : Getting local computer information: HAL
Getting HAL information
Property HALName is now = acpiapic
Finished getting HAL information
Update progress [ 20 ] : Getting local computer information: Networking
Getting network info
Checking network adapter: [00000007] Intel(R) PRO/1000 MT Network Connection
MAC address = 00:00:00:00:00:00
IP Address = 192.168.105.112
IP Address = feee::111:999:1000:5555
Default Gateway = 192.168.105.1
Property IPAddress001 is now = 192.168.105.112
Property IPAddress002 is now = feee::111:999:1000:5555
Property MacAddress001 is now = 00:00:00:00:00:00
Property DefaultGateway001 is now = 192.168.105.1
Finished getting network info
SUCCESS: 0: GetNetworkInfo for Gather process
Update progress [ 25 ] : Getting local computer information: Distribution point
Getting DP info
Unable to determine ConfigMgr distribution point
Finished getting DP info
Update progress [ 30 ] : Getting local computer information: Windows Deployment ServicesGetting WDS server info
Unable to determine WDS server name, probably not booted from WDS.
Finished getting WDS server info
Update progress [ 30 ] : Getting local computer information: Host name
Property HostName is now = wds-mdt-server
Update progress [ 30 ] : Getting local computer information: Asset information
Getting asset info
Property AssetTag is now = No Asset Tag
Property SerialNumber is now = VMware-56 4d 49 ea 9a 30 be 22-a5 55 c1 10 36 3f 02 e4
Property Make is now = VMware, Inc.
Property Model is now = VMware Virtual Platform
Property Product is now = 440BX Desktop Reference Platform
Property UUID is now = EA494D56-309A-22BE-A555-C110363F02E4
Property Memory is now = 6143
Property Architecture is now = X64
Property ProcessorSpeed is now = 2660
Property CapableArchitecture is now = AMD64 X64 X86
Property IsLaptop is now = False
Property IsDesktop is now = False
Property IsServer is now = False
Property IsUEFI is now = False
Property IsOnBattery is now = False
Finished getting OS info
SUCCESS: 0: GetAssetInfo for Gather process
Update progress [ 35 ] : Getting local computer information: Operating system
Getting OS SKU info
Property OSSKU is now = SERVERSTANDARD
Finished getting OS info
SUCCESS: 0: GetOSSKU for Gather process
Update progress [ 40 ] : Getting local computer information: Operating system
Determining the Disk and Partition Number from the Logical Drive C:\Windows
SUCCESS: 0: GetCurrentOSInfo for Gather process
Update progress [ 45 ] : Getting local computer information: Virtualization
Getting virtualization info
Property IsHypervisorRunning is now = True
Property SupportsVT is now = False
Property SupportsNX is now = False
Property Supports64Bit is now = True
Property SupportsHyperVRole is now = False
Property IsVM is now = True
Property VMPlatform is now = VMware
Finished getting virtualization info
Processing the  phase.Determining the INI file to use.
FindFile: The file CustomSettings.ini could not be found in any standard locations.
Finished determining the INI file to use.
Update progress [ 100 ] : Gathering complete, but no INI file found.
Unable to find rules INI file, rc = 1
ZTI ERROR - Non-zero return code by ZTIGather, rc = 8000

The CustomSettings.ini file exists in the Control directory, and I only have one. What gives?

Short of creating a new deployment share (or starting from scratch), I'm not sure what to do.

CustomSettings.ini Below

[Settings]
Priority=Default, DefaultGateway, SysSerial, SysModel, ModelAlias, ComputerName, Final
Properties=Site, DebugEcho, SysSerial, SysModel, ModelAlias

[Default]
DeployRoot=\\wds-mdt-server.f.q.d.n\DeploymentShare$
SLShare=\\wds-mdt-server.f.q.d.n\deploymentshare$\Logs
SLShareDynamicLogging=\\wds-mdt-server.f.q.d.n\deploymentshare$\Logs
EventService=http://wds-mdt-server.f.q.d.n:9800
OSInstall=YES
SkipWizard=YES
SkipFinalSummary=YES
DeploymentType=NEWCOMPUTER
SkipAdminPassword=YES
AdminPassword=securep455w0rd!
'SkipDomainMembership=YES
'JoinDomain=DOMAIN
'DomainAdmin=AD-Admin
'DomainAdminDomain=DOMAIN
'DomainAdminPassword=@nOTh3Rsecurep455w0rd!
SkipTaskSequence=YES
'Most workstations should be using this Task Sequence
TaskSequenceID=APW7_002
KeyboardLocale=en-US
UserLocale=en-US
UILanguage=en-US
TimeZone=035
TimeZoneName=Eastern Standard Time


[DefaultGateway]
192.168.105.1=VLAN105
192.168.44.1=DC
192.168.43.1=DC
192.168.42.1=DC
192.168.41.1=DC
192.168.40.1=DC
192.168.39.1=DC
192.168.38.1=DC
192.168.37.1=DC
192.168.36.1=DC
192.168.35.1=DC
192.168.34.1=DC
192.168.33.1=DC
192.168.32.1=DC
192.168.31.1=DC
192.168.30.1=DC
192.168.29.1=DC
192.168.28.1=DC
192.168.27.1=DC
192.168.26.1=DC
192.168.25.1=DC
192.168.24.1=DC
192.168.23.1=DC
192.168.22.1=DC
192.168.21.1=DC
192.168.18.1=JPDESK


[DC]
DeployRoot=\\wds-mdt-server.f.q.d.n\DeploymentShare$
Site=DC
_SMSTSOrgName=A&P %Site% Imaging (CS)

[MYDESK]
_SMSTSOrgName=A&P Workstation Architect Mode
DeployRoot=\\wds-mdt-server.f.q.d.n\DeploymentShare$
OSInstall=Y
SkipCapture=NO
SkipAdminPassword=NO
SkipProductKey=NO
SkipComputerBackup=NO
SkipBitLocker=NO
SkipTaskSequence=NO
'------------------BEGIN EDITS HERE
Site=MYDSK
OSDComputerName=%Site%-%SysModel%-%SysSerial%
DebugEcho=True

[VLAN105]
DeployRoot=\\wds-mdt-server.f.q.d.n\DeploymentShare$
Site=VLAN105
_SMSTSOrgName=A&P %Site% WDS Imaging (CS)
DebugEcho=True
OSDComputerName=%Site%-%SysModel%-%SysSerial%


[SysSerial]
UserExit=SysSerial.vbs
SysSerial=#SetSerial()#


[SysModel]
UserExit=SysModel.vbs
SysModel=#SetSysModel()#


[X20]
SkipTaskSequence=YES
'Task Sequence unique to this system type
TaskSequenceID=CITRIX-001


[ComputerName]
ComputerName=%Site%-%SysModel%-%SysSerial%
OSDComputerName=%Site%-%SysModel%-%SysSerial%


[Final]
'_SMSTSOrgName=A&P %Site% Imaging

I went ahead and updated my MDT 2013 Update 1 to Update 2. I had issues upgrading the deploymentshare(s) themselves, but I was able to get through it; however now I am unable to create a new boot file from the deploymentshare itself.

below is the error that I get!