Category Archives: MDT 2012

Microsoft Deployment Toolkit 2012

Wrangling Windows 10 File Associations – SetUserFTA

As of late, I’ve been almost exclusively focused on Windows 10 deployment, and depending on what you’re trying to do, the process can be complex. There’s a wealth of knowledge out there already, but truthfully, getting a machine imaged or upgraded is the easy part. As someone with a bit of OCD, the true challenge is making sure the user’s first experience on the machine is perfect! In this case, that means making that experience as close to Windows 7 as possible 😉

With Windows 10, Microsoft has moved to develop an OS that’s more secure out of the box. That’s great, and hopefully will make our lives easier in the long run. The trade-off is that some tasks that were once pretty easy, are now painfully difficult. One of the worst? File associations.

I know I know, someone is going to tell me ‘just let the user choose!’ For anyone who hasn’t done it recently, the process to make another web browser the default or change a file association in Windows 10 is 4-6 clicks, and several dialog boxes popping up. If that isn’t training my users to just click ‘Yes’ on anything that pops up on their screen, I don’t know what is! I’m far less concerned with an OS that let’s me configure things silently, and far more with one that trains my users with bad behavior.

Official documentation on setting file associations has existed for quite some time, but I’ve seen varying success depending on the version of Windows 10 as well as the customer environment I’ve tried it in. Microsoft, for their part, has *finally* (it took 2.5 years) released a blog post on configuring default application associations that should be more broadly applicable. You can read that here, and then cry for a few moments as you understand how difficult this is to accomplish for the following scenarios:

  • I only want to set associations once, not continuously
  • I only want to set associations on a per-user basis
  • I want to set associations with a roaming profile (or UE-V) <- This one was mentioned to me on Twitter, I haven’t had time yet to confirm that MSFT’s blog post does/doesn’t work properly in this scenario, but it wouldn’t surprise me.
  • I want to set associations without having to set *all* file associations at once
  • I want to set associations without losing hours of my life to reading a blog post and fiddling with XML files, DISM, and GPO’s (Don’t get me wrong, these are a few of my favorite things, just not in this context)

Luckily, heroes like Christoph Kolbicz exist (His blog is here)! He recently posted about a new tool to write user-specific registry keys that set and keep Windows 10 file-type associations painlessly. I was too curious, so I put his new app, SetUserFTA to the test! (Note: I’m using v1.1.1 – the current version at the time of this post)

The easy way – Setting Adobe Reader as the default PDF Viewer

  1. Install Adobe Acrobat DC (Older versions recently went out of support, so make sure you’re on DC for the latest security fixes 🙂 )
  2. Manually associate Adobe Acrobat DC with PDF’s. This can be done several ways, but I’m showing the process from the ‘Default App Settings’ page in the ‘Settings’ area of Windows 10.
  3. Look up the Program ID (Also noted some places as the AppID) for Adobe Acrobat DC. The ID is the third item returned from the command below. This seems to change version to version on some apps, so make sure you check your own system before assuming that the Program ID I’m using will work for your version of Adobe Acrobat DC.
    1.  For your copy/paste pleasure:
  4. Run Christoph’s app with the file extension you want to associate, and the Program ID you’ve just looked up, on any computer you want to update associations on.
    1. More copy/paste code:
  5. Watch your screen flash for a moment, then bask in the glory that is a silently set, per-user, file association!

I love this for so many reasons. Focusing on desktop deployment and user experience, I can use this to ensure that when a new app is installed, the file association is set at the same time, without any user intervention! Here’s a quick and dirty PowerShell script that installs Adobe Acrobat DC and sets the PDF file association in one fell swoop! Note – this doesn’t accept the Adobe Reader EULA or anything like that, this post is about setting file associations, not installing Adobe Reader end to end 🙂

This is great! No DISM, no copying/editing of XML, and the end result is achievable in 5 minutes instead of many, many more.

I’m not even going to dive into the Microsoft-endorsed method at this point. I’ve done it before, it works, but it allows little flexibility. Microsoft’s methods may work for you, and if so, keep at it! Once you get tired of that, SetUserFTA is a great alternative.

It looks like Christoph is using this for Citrix environments, which I can imagine must have been hell to manage with MSFT’s official guidance, thus why he spent the time building all this 🙂 SetUserFTA ought to come in handy for anyone doing app deployment, Citrix or VDI environment management, or who just doesn’t want to deal with Microsoft’s own methods of setting app associations up. Give it a try and let me know how it goes via Twitter @systemcentersyn

What’s next? I am hoping Christoph continues development and let’s me set protocol associations, so web browser selection and deployment becomes just as easy 😉 Also, here’s to hoping that anti-virus apps stop flagging his .exe as a virus, as that’s held me up a few times as I authored this post. AV heuristics can be both a curse, and a blessing. Update: Christoph has re-uploaded v1.1.1 with updated code that my Anti-Virus finds less suspicious. No issues now!

Using this? Does it work for you? Tweet @_kolbicz and be sure to donate as thanks for his efforts! Again, the blog post for instructions and download of the SetUserFTA app is here.

MDT 2012 Error – Invalid credentials: A specified logon session does not exist. It may already have been terminated (80070520)

Mondays! I swear, all the fun stuff happens on Mondays…

Well, I’ve officially put in my two weeks notice at my current job, and am heading to become a full-time System Center consultant! I’m super excited. That said, it has created a long list of “to-do’s” before I leave my current position, which is what I am now trying to dig myself out from under.

One of the tasks I had was getting a Windows 8.1 Image up on our MDT server. No one was asking for it, but that’s often how things go in Higher Education – no one will ask for it forever, then one day decide they need it tomorrow. To save my coworkers the trouble, I figured I’d just do it now.

Anyway, after capturing the image and setting up the new deployment task sequence, I did my first trial deployment. It worked just fine from the boot cd, but not when running ‘litetouch.vbs’ from the network share. I was perplexed.

Specifically, I was getting this error:

Invalid credentials: A specified logon session does not exist. It may already have been terminated ( 80070520 )

I double checked my connection credentials, and they were, in fact correct. What ended up being the issue is that, somehow, similarly to the issue I posted about earlier on this blog, my permissions on my Deployment Share got messed up again.

I removed, saved, and re-added all the necessary permissions on our deployment share, and all is now working again! A simple fix to a simple error.

MDT 2012 Error – FAILURE: 8000

So we’ve got a few deployment servers here at the office, all of which I admin. Our production one is a bit old, so I set up a new MDT 2012 server to test things out on. It just so happens I do all the cool stuff on the test server, so sometimes our test becomes our production; welcome to IT in Higher Education!

Anyway, my co-workers were imaging from my test server one day when I got the complaint that imaging was no longer working. I was confused. I hadn’t touched anything lately, but I went to take a look.

The deployment would all of a sudden just stop. No errors (visibly), no screens, I was just left with the background of an MDT Windows PE session. Sigh.

I opened up ztigather.log with CMTrace (If you haven’t added this to your Mini PE disk, you’re missing out!) and found the following error: FAILURE: 8000: Running wscript.exe "X:\Deploy\Scripts\ZTIGather.wsf" /nolocalonly1

I wasn’t quite sure what in the world this meant, so I googled. Not much luck. I found a few notes about trying to run the ztigather.wsf script manually by copying the unattend.xml from the deployment share to the locally created ramdrive, so I attempted to do so.

Looking through the logs I could see that it mounted my deployment share properly at ‘Z:\’ so I didn’t suspect anything wrong at first, but when I tried to path out to actually get my unattend.xml file… I couldn’t!

As it turns out, my permissions on my Deployment Share permissions had changed, and the task sequence could no longer access the files on that share. That’s why nothing was showing up! It kept waiting to get files from the deployment share, and it never got anything back.

I remoted into my MDT server, went to my deployment share, made sure that permissions were set back to where they needed to be (Honestly, since it was easier and this is just my test server, I set it to allow ‘Everyone’ read permissions for a short time.) and all was well! We could once again deploy like MDT intended.