WDS MDT Debugging seems a nightmare - Is it supposed to be that hard or do I lack experience?

Brass Contributor

I am new to WDS, MDT in a company.

 

I created deployment shares and debugging them was very hard without asking the senior guys.

 

Is there a best practice, especiallz on finding out which part are missing in Bootstrap.ini, unattanded.xml, task sequence, rights management.

 

Also linking deployment shares gave me strange effect, so that the cloned deployment share did not work, because it did not copy everything.

 

WDS Deployment would sometimes not start because I used the wrong install.wim to build my image, after setting some variable to false, it then used the WDS servers local wim and things suddenly worked. These seem all strange effects and it seems a hard task to find such errors without experience.

 

Please provide me with debugging resources and advice for deployment without the SCCM, because we can not afford that for out 4000+ machines.

 

Thank you.

Kind regards.

Christian

5 Replies

That's a rather broad question :)  We do provide a lot of docs to help at https://docs.microsoft.com/en-us/windows/deployment/index, including step-by-step guidance.  The forums here, as well as mailing lists hosted by MyITForum.com on MDT and OSD, can help too.

 

 

Yes, I read all of that, but the most interesting bit is missing - DEBUGGING. And debugging WDS is really hard, as the deploy just fails and one has no idea why, when for example the DeploymentShare did not have the right permissions or there the deployent share path was using the netbios name instead of the FQAN. No component told me that, I just had to find out by myself. This really kills productivity, as you can imagine that this search is not trivial, especially as a newbe.

 

I especially read this bit:

 

https://docs.microsoft.com/en-us/windows/deployment/deploy-windows-mdt/deploy-windows-10-with-the-mi...

 

as this is what we are using, but we have our own DNS, DHCP Server, which is not a Microsoft Server.

 

Where is the - HERE IS WHAT YOU DO WHEN THINGS GO WRONG - part that is orded by which phase of the deployment it concerns?

 

Linking shares and syncing them also does not do what one would expect. Comes down to the same point, no Debugging help, just figuring out by yourself that the bootstrap.ini, some rules in the share's properties, background image path of the x64 target were not copied.

Dear Michael,

 

this is just an observation, maybe it is wrong, as I am fairly new to the Windows world. My history started in Windows 8 years ago, when I developed in C#, then I dived into the Linux world completely and became really hard core, Java Development, compiling kernel module, configuring the most obscure systems and all that. Then I came bcak to Windows, that is Windows 7 and mostly Windows 10. To tell the truth, I was amazed at what I saw, because there was this giant, Microsoft, that actually managed to come out of the deep freeze, by finally realizing that the world went on, mainly of course because Apple came around and showed Microsoft that they really had no taste and Apple's quick adoption rates might have even frightened Microsoft just a little bit.

 

Then I started working with Windows Active Directory, WDS, WSUS, Centrify and also was amazed that it was possible to deploy a system that actually did what was written in the documentation and even worked after I went through the drill of setting it up. Within a couple of days, I had a test AD with multi factor auth, role based authorization and was even able to tame MacOS within the Domain with that and integrated all kind of open source OSes. And it all worked just like that. This was unknown to me after several years of open source, as their documentation is mostly useless, out of date, etc.

 

Sorry a lot of introduction to my point, but stay with me, please.

 

Then I dove into Windows 10 and its deployment as this is what I am responsible for in my new job and found the release cycle CB/CBB, at the time it was said 2 months preview, 4 months CB, 6 months CBB, 2 months grace. I communicated that to our companies admins. I thought, wow, Microsoft is actually going kind of agile. Then Microsoft got pressure from the really big customers and caved, why? You tell me, but maybe, just maybe it has to do the the absolutely crap deployment tools that you provide. They are horrible. Why?

 

- They behave randomly.

- They are really badly documented. (yes, you can set them up when you start from scratch very easily, but that is not my reality, there is history here.)

- Compared to the Linux world they are decades behind.

- Logging and Debugging capabilities are really bad. I can not speak a SCCM, because I never used it, just WDS with MDT. SCCM is prohibitively expensive for us and politically problematic. Maybe that would be the solution to all our problems, but I am not even allowed to look into them.

 

Then Microsoft stopped the agile ride partially by introducing 12-22 months. What is that anyways, 12 - 22 months?? Imagine someone really wants to plan upgrade paths, how can you plan with a 10 month uncertainty if your core business depends on it? But that is another story.

 

However coming to the main point. At least this combination of of WDS/MDT is not fit for quick (agile) deployment cycles anyways as it does not provide sufficient debugging capabilites and automation capabilites on the level of testing the WDS deployments themselves. Had you stayed with 6 months for CBB you would need a continuous deployment testing for companies which is very hard with the tooling you have at the moment, if not impossible, because everybody, who is meticulous about deployment, would need to automatically test primary deployments of all shares, in place upgrades and all software deployments and would have to do functional testing of the core services and software functionality within the deployed operating systems.

 

So I am asking you, if a nobody like me can figure that out, why did't Microsoft and provided the proper tooling for that?

 

Now I stop ranting and would like to finish by saying that Microsoft Security Graph and ATA is the most advanced security concept I have seen in IT, no open source OS can keep up with that, although the privacy concerns are there, but the idea is really good.

 

Hope you consider some of my thoughts as it seems Microsoft started listening.

Kind regards.

Christian