[mdt] Broken MDT again

[garethEds]

Afternoon Everyone,

 

My MDT server has broken. Will not connect to the database during deployment for some reason. This isn't the first time it has happened and it's annoying. So has anyone looked at other deployment solutions? I'm fed up of MDT and have no time to rebuild the server.

 

I've considered SmartDeploy - but it is too expensive for schools.

 

What else is there that does deployment from the original wim and then target driver selection. I'm not bothered about apps as we have PDQ Deploy to do that. Also want it to name machines based on Mac address. Like MDT - but not MDT.

 

Cheers

 

Gareth

[mavhc]

I just use wds, windows update gets all the drivers.

 

You can use cmd line to prepopulate the mac vs names

[Olliedawg]

MDT is so easy to break lol. Once I got ours working with win11 I only touch it unless absolutely necessary..

 

As above unless you've got some specific peripheral which requires certain driver/s, i'd let WU handle the drivers. I ditched driver packs a while back & just added a step into my MDT TS after installing applications to grab any drivers from WU. Not had any issues so far with my machines imaged this way

[garethEds]

MDT is so easy to break lol. Once I got ours working with win11 I only touch it unless absolutely necessary..

 

As above unless you've got some specific peripheral which requires certain driver/s, i'd let WU handle the drivers. I ditched driver packs a while back & just added a step into my MDT TS after installing applications to grab any drivers from WU. Not had any issues so far with my machines imaged this way

 

HI Mate - it's the dabase connection that has broken again. Not sure why.

 

As for the drivers - what step did you add into your task sequence? Anmy chance you can DM me some screenshots of the task step?

 

Cheers

 

Gareth

[Olliedawg]

HI Mate - it's the dabase connection that has broken again. Not sure why.

 

As for the drivers - what step did you add into your task sequence? Anmy chance you can DM me some screenshots of the task step?

 

Cheers

 

Gareth

 

Ah - i've never come across that problem.. assuming easiest way to fix that is rebuilding? Or restoring the VM to a previous date

 

This is what I've done

 

Add a TS step "Run Command Line" into the "State Restore" section. I've got mine straight after the application installs.

 

Run Command Line :

cscript.exe "%SCRIPTROOT%\ZTIWindowsUpdate.wsf" "IsInstalled=0 and Type='Driver'"

 

Basically just runs windows update but only searches for drivers.

[DrCheese]

MDT is EOL now, It doesn't offically support Windows 11. They want you to use SCCM instead (or autopilot) - Although I've bodged MDT to work with 11...

[ITGuyNW]

Yeah I've been looking at Microsoft Config Manager as a replacement as it'll have to be used at some point down the road.

[jthompson]

RE: MDT database connections, I know that when using Windows 10 2004 ADK or earlier, TLS 1.0 needs to be enabled on the server for the client to be able to connect to the database.

 

I've never used FOG, but that's the only other thing that I know of that might be worth considering apart from plain WDS. SCCM (or MECM or whatever it's called this week) is probably a faff to set up but perhaps worthwhile in the long run. We switched to MDT from WDS when our WDS stopped being able to auto join new computers for some reason that we never got to the bottom of.

[3s-gtech]

I got my MDT to support Windows 11 and build a Lenovo E16 yesterday (so fairly up-to-date kit). I just put Windows 11 Edu into a copied task sequence, updated the WinPE drivers and updated the WDS boot image. It seems to work absolutely fine still.

 

Not had to rebuild mine in the few years I've had it - what's changing when it breaks? Windows Update doesn't seem to kill it.

 

Worth doing snapshots or having decent backups - ours doesn't have them as it's a fairly dumb physical server and takes up too much storage, but not a massive deal.

[mavhc]

RE: MDT database connections, I know that when using Windows 10 2004 ADK or earlier, TLS 1.0 needs to be enabled on the server for the client to be able to connect to the database.

 

I've never used FOG, but that's the only other thing that I know of that might be worth considering apart from plain WDS. SCCM (or MECM or whatever it's called this week) is probably a faff to set up but perhaps worthwhile in the long run. We switched to MDT from WDS when our WDS stopped being able to auto join new computers for some reason that we never got to the bottom of.

 

Because you switched to UEFI and it had a bug that added a deny ACL to the computer account

 

param (
   [Parameter(Mandatory=$true)][string]$computerName
   )
Import-Module ActiveDirectory
Set-Location AD:\
$computer = Get-ADcomputer $computerName
$acl = (Get-ACL "AD:$($computer.distinguishedname)")
foreach ($access in $acl.access) {
   if ($access.AccessControlType -eq "Deny"){
           write-output "Removing" $access.IdentityReference "Deny"
           $acl.RemoveAccessRule($access) #| Out-Null
   }
}
Set-ACL -AclObject $acl $computer.DistinguishedName -Verbose
set-location c:

[MartinT]

Have you changed the account password for MDT access recently, and remembered to modify the two scripts that need the password?

[aac]

We used MDT years ago and had strange issues that essentially broke MDT entirely when importing drivers it did not like resulting in an almost annual rebuild of the server. We have been using MECM now for a number of years and have had zero issues, we use Big Bang UIU Utility which covers drivers for 90% of all our devices apart from our teacher laptops (Dell) which we import the driver pack for but only because we want to ensure the drivers are easily updated for them when re-imaging...

[PotNoodleTech]

Bizarre been running MDT for like 10 years here never had to rebuild a server or database or anything. Mind you have mostly had Dell PCs on there which have good driver packs no random makes and models.

[highsky]

How many clients?

Is SCCM an option?

Do you want to move away or having it working again will do?

An option will be a full migration and reusing the same ip, sharess, and builds afterwards.

 

https://community.spiceworks.com/t/migrate-mdt-to-new-server/1012432

 

Any experience with Friends of MDT?

[garethEds]

So what I've done is - remove all SQL software from the MDT server. Cleaned it up, restarted etc. Re-installed all SQL softwrae and reset it up with a new database. Nothing - nada. Still will not connect.

 

WHat am I missing

 

GJE

[jthompson]

Anything in the client logs? The only thing I can think of to suggest is checking whether you've got TLS 1.0 disabled on the server. If you have, try turning it back on for a test.

[garethEds]

Anything in the client logs? The only thing I can think of to suggest is checking whether you've got TLS 1.0 disabled on the server. If you have, try turning it back on for a test.

 

Will look at the logs again but it's the 'Processing rule: CSETTINGS' that is taking the time as it clearly is trying to connect to the database. MDT can see the database as all machine names are listed. I've checked all the permissions - the deployment account has the permissions to access and read the database. The named pipes are all enabled.

 

The SQL share is fine and visible. Logs said nothing yesterday, but will try them again today. TLS 1.0 is enabled as a test. Still happening. I'll post logs once the machine has tried to build again. I'm stumped.

 

Gareth

[garethEds]

Here is a picture of the logs - Don't mind the server name in there. Not sure why it cannot connect to the SQLShare - nothing has changed. It's all setup like it was.

[garethEds]

Here is a picture of the logs - Don't mind the server name in there. Not sure why it cannot connect to the SQLShare - nothing has changed. It's all setup like it was.

[ATTACH=CONFIG]71665[/ATTACH]

 

HOw does one set the SQLShare name? It says in MDT to set it as the Deployment Share path - so I'm sure that is what we always did.

 

Gareth

[Steve21]

Going back a step, with those 0x80070035 errors, can you manually browse to the share/ping the server etc from the client while it's building/breaking? (Assuming it hasn't changed in MDT it's like pressing F8 to open a command prompt during the PXE).

 

At least that way you'd be able to confirm things like DNS is happy, drivers are connected to check network connections, does it resolve the hostname etc, does the account let you manually log into the share by just entering the credentials you're using etc?

 

Might not be anything SQL side if it's not even finding the machines due to a missing NIC driver/DNS issue etc

 

Steve

[jthompson]

The errors before the attempt to connect to the database are likely where your issue is. Those log entries say that it's trying to connect without a username. Are you expecting that? I'd have thought you'd be providing credentials for the client to access the deployment share.

[jthompson]

We don't put the user creds in the bootstrap.ini file. WinPE will then prompt for credentials when it first attempts to access the share. That's how we do it, to prevent anyone other than us from initiating imaging.

[garethEds]

Okay - we are connecting to the share. Latest build showed 2 errors. With Named Pipes we've never had to enter credentials. I can add then if I need to though. Here is the latest log. I cannot understand what would have changed recently to cause this.

 

 

I'll add the credentials to the database and go from there again.

 

GJE

[jthompson]

I think the credentials are for accessing the deployment share as a whole, rather than for the database as such.

 

I think you're missing the "SQLShare" parameter in your CSettings. This is the CSettings section from our deployment share rules:

 

[CSettings]
SQLServer=MDTServerName
Instance=SQLEXPRESS
Database=MDT
Netlib=DBNMPNTW
SQLShare=DeploymentShare$
Table=ComputerSettings
Parameters=UUID, AssetTag, SerialNumber, MacAddress
ParameterCondition=OR

[garethEds]

I think the credentials are for accessing the deployment share as a whole, rather than for the database as such.

 

I think you're missing the "SQLShare" parameter in your CSettings. This is the CSettings section from our deployment share rules:

 

[CSettings]
SQLServer=MDTServerName
Instance=SQLEXPRESS
Database=MDT
Netlib=DBNMPNTW
SQLShare=DeploymentShare$
Table=ComputerSettings
Parameters=UUID, AssetTag, SerialNumber, MacAddress
ParameterCondition=OR

 

I had that in there but took it out at one point. Are you putting the name of your share in there? Our share name is MDTDeploy$ or are you putting in the words 'DeploymentShare$'. It's clearly a permission issue somewhere.

 

Gareth