We had given a user a brand new computer because a BSOD we could not solve, and the transition to the new PC had not been smooth. For one, the user was a manager and had more applications than the average user. Also, the tech dealing with the new PC was quite fresh, and, as we found out later, the tech did not have sufficient permissions to image new PCs.

I started by helping the tech reinstall the Software Center client, and install other applications. All seemed well until the user mentioned that he/she was missing his/her mapped drives.

We tried doing a GP update. Nothing.

Restart. Nothing.

I took a look in Event Viewer, and I saw a warning saying, “Folder redirection policy application has been delayed until the next logon because the group policy logon optimization is in effect.”

That explained where the mapped drives went, but why?

I took a look further back in event viewer, and I saw a bunch of errors that looked similar to the one below:

This led me to take a look at the printers. I connected to the print server, and I tried to connect to one of the printers. I got an error like the one shown below:

These errors are usually related to printer drivers issues. My supervisor sent me this link with the following instructions:

1. Open Registry (click Start > type regedit in the search box > press Enter) on a machine with the same driver installed which works fine, and then expand the key: HKLM\System\CurrentControlSet\Control\Print\Environments\Windows NT x86\Drivers\Version-3\

2. Expand the subkey corresponding to the printer driver you are dealing.

3. Click the subkey, and expand InfPath in the right pane, and then note the path.

4. Browse to the directory according to the above path.

5. Go to the C:\Windows\System32\DriverStore\FileRepository of the machine you want to install a printer, and check if the folder is present.If it is here and it is empty, you will have to modify security on the folder, first taking over ownership, and then granting yourself full control.

6. Copy the contents of this folder from a good machine to the machine presenting the 0x00000057.

7. Try connecting to the print queue on the print server. The driver should now download and install properly.

I followed the instructions, messed up permissions for the file repository (I accidentally deleted the permissions for the Everyone security entity), and then fixed what I had messed up. After all this, the user had all his apps and drives and was up and running.

My theory as to why all this happened is as follows: This user had many printers mapped to his profile. When all of them failed to map because of the faulty driver, the folder redirection policy was delayed, causing the user to lose his mapped drives.

Needless to say, a lot of writing went into explaining this one to my manager and posterity.

This one actually happened before I started working in Desktop Support. In fact, what I am about to tell you did not even take place at work, it actually took place in a hospital. To be more specific, in the hospital my wife was in to give birth to our daughter.

My wife and I were sitting in the room waiting for a nurse to come to take my wife`s vitals for the first time. When the nurse came in, she turned on the monitor next to the bed, but for some reason, it would not turn on. Fearing that this would require a call to Desktop Support, and more delays, I took matters into my own hands.

I walked behind my wife`s bed, and behind the monitor. I took one look and thought “simple first”. Using this rational I took the power cable and gave it a good shove into the power socket behind the monitor.

Of course, the monitor turned on. Cue the shocked faces.

Not too long after this incident, I got my first desktop support job. I always wonder if this somehow led me to find that job.

Well actually control characters, but I really really like the title. So…

Well, it all started as an escalated issue. My manager asked if I could help with an interesting problem. A user was copying text from Outlook into search bars in different sites, or into the database, and for some reason, the pasted text always contained extra characters.

It took us a while to realize that the extra characters being copied, were actually special characters. We started looking into Outlook itself. We went through all the settings, but couldn’t find anything obvious.

We then spoke with administrators of the website and database; still nothing.

It then occurred to me that we may have gone through all settings thoroughly, so I took another look at the Outlook settings. Under File > Options > Mail > Editor Options > Advanced I found this:

Problem solved!

Interesting to note that this only happened when pasting in certain sites. Other site like Google did not have this problem.

As I wrote about yesterday, there seems to be an issue upgrading to Windows 10 1709 when the OEM license in the BIOS is a different version than the one actually installed. I also mentioned yesterday, that our primary method of upgrade would be through SCCM using Task Sequence.

Well, today I found this article by Adam Gross, and well, this is exactly the same issue we were experiencing. More importantly, the solution mentioned in the article worked when we tried it, and we are now able to move forward with the upgrade to Windows 10 using SCCM.

What is interesting is that this issue is really hard to find on the internet. It took me googling different lines from the SCCM logs to finally find Adam`s post. I can only imagine, that as more and more administrators roll out Windows 10 1709 we may see more posts about this issue.

I have teased this issue in the past here and here. And today, with a little bit of help, I figured it out.

Let`s start from the beginning.

The company I work for began the process of rolling out Windows 10 this past summer (this makes sense as support for Windows 7 ends in about 23 months). I was designated as the one responsible for making sure the rollout commenced, the upgrade worked, and that users would not be adversely affected by the change. Most of the upgrades would be from Windows 7 Enterprise to Windows 10 Enterprise through SCCM.

Things began smoothly enough. We had some minor issues in the beginning with the A/V, and the profile management service we were using, but all in all, things seemed to be moving along pretty well.

This all changed with the Fall Creators Update. For some reason, certain machines would fail to upgrade. No matter what we tried the upgrade kept failing (upgrades to Creators Update worked fine).

The error code that kept showing up in the SCCM logs ended in 204, which indicated that there were some incompatibilities between the current OS and the OS we were trying to upgrade to. This was so strange as the machine was running Windows 7 Enterprise, and we were trying to upgrade to Windows 10 Enterprise.

One of us finally had the brilliant idea of running the ISO downloaded from the licensing portal to see what would happen. And wouldn`t you know it, the upgrade tried to install Windows 10 Pro. Hmm…

Now is probably a good time to let you know that the Fall Creators (1709) ISO came with Pro, Enterprise, and EDU all lumped together. It would be up to the installer to decide which version to install. This lumping together had something to do with our issue because as I said before Creators Update (1703) upgraded fine. The 1703 ISO comes with only one version so you have a 1703 EDU, a 1703 Enterprise etc.

However, this by itself could not be the problem, because these PCs clearly had Windows 7 Enterprise installed. I mean it said it right there in the system properties.

Another thing I must tell you is that these were the first PCs we ordered that came imaged with Windows 10 (Pro). This means that there was a license for the OS embedded in the motherboard. However, we didn’t use the OS the PCs came with, rather we would swap out the HDDs for SSDs, and then image the PC with an enterprise OS.

Sooo… it would seem that the upgrade was picking up the license still embedded in the motherboard. But could we prove this? Well as a matter a fact yes we could. There is a tool, called ShowKey Plus, which will retrieve the product key from the registry or even BIOS (kudos to Into Windows for the information about the tool).

ShowKey Plus confirmed what we suspected: There were two Product keys on the PC. One, for enterprise, installed with the current OS, and one, for pro, in the BIOS.

With the cause of our problem confirmed, it was now time to come up with a solution. I came across a post from the Superuser site. The user’s problem seemed similar enough to ours that I thought I would give the solution a shot. I added a file to the sources directory in the ISO called PID.txt. In the file, I typed [PID] followed by the product key. After this, I ran the ISO and thank goodness it picked up the product key and installed Windows 10 1709 Enterprise.

Now we just need to make it work in SCCM, and move forward with our rollout.

The tool was created by Joe Richards to allow a password to be past to the command line, and to startup up applications with network credentials. The alternative to this, RUNAS from Microsoft, didn’t allow for the former, and required the command to be run every time to satisfy the latter.

(You can read more about it here. You may notice that the last time the tool was updated was in 2005. When I asked the Windows Admin who set up CPAU for us about this, he just shrugged his shoulders.)

As an unintended consequence (and this is totally how CPAU was being used at my workplace), admins began using CPAU in their batch files when needing to run certain applications as a local admin.

The process of creating these batch files is quite simple. First, make sure the user name that will be running the application is in the local administrators group. Second, download the exe file from the Joeware site. Third, create the job file. The syntax for the job files look something like this:

Finally create the batch file that runs the job file. If you want to make life easier for the user, then create a shortcut to the batch file and place it on the users desktop.

As a final note, I feel it is necessary to mention that there are more modern ways of making sure certain applications, for certain users, run with elevated privileges. For example, Application Control from Appsense will allow you to discover which applications require elevated credentials, and then create an elevated privilege policy to be applied to a specific group of users. You can read more about Application Control here.

As you may have read here I managed to mess up my PC`s BIOS, thereby rendering my motherboard useless.

(Still too embarrassed to say how i managed to mess that one up).

On Friday the MFR sent over a brand new motherboard under the warranty. However, unlike previous times (yes there have been previous times), this motherboard came without a tech.

This presented a number of challenges. Firstly, the serial number of the PC must be updated in the BIOS, which is something the tech is supposed to do. If this is not done, then the user will get an alarming beeping noise and a BIOS error whenever they boot up their PC.

Secondly, and most importantly, is that up to this point I had never changed a motherboard before. Plain and simple.

Don`t let that stop me.

Right off the bat I realized that I did not have an ESD bracelet. No matter, I told myself, as I grounded myself through the PC`s power supply. Next, I noticed that we did not have non-magnetic screwdrivers. Again, no matter, as I decided to risk it using my magnetic drill.

I began by unscrewing the fan and moving the CPU to the new motherboard; Simple enough. Then I began to unplug all of the cables, which brought on the I-won`t-remember-where-the-cables-are-supposed-to-go anxiety, or IWRWCASTGA for short. Then I unscrewed all 8 or so screws, and took out the board.

The next part should have been a cinch, and initially it was. I placed the new motherboard inside the case, tightened all the screws, and even managed to place all the cables back in their original one (except for the one that connects the power button to the motherboard).

It was when I was trying to tighten the screws for the CPU fan that I noticed I had a problem. For some reason the screws would not tighten. I looked into the holes where the screws were supposed to go, and I saw nothing. It was like looking into a deep dark abyss. At this point it occurred to me to check the bottom of the old motherboard, and I noticed a bracket holder. So I removed it, and after some more unscrewing, cable removing, and screwing I had my new motherboard all set up and ready to go.

At this point everything should have been peachy keen, but it was not. As you may recall from a few paragraphs back, when a motherboard is replaced, the serial number for the computer must be updated in BIOS. Otherwise, the PC will make an annoying beeping sound at boot and show a BIOS error.

For some reason I was unable to get around this beeping sound. Every time I tried to boot, it would not pick up the OS in the hard drive, and continued looping through PXE. This continued for a bit, until I changed the BIOS to boot in legacy mode. The PC booted all the way to the Windows login in screen…

…but that was as far as it was willing to go. I believe this had something to with the OS not knowing what to do with the new hardware, and causing the hardware abstraction layer to not work properly.

To make a long story short, I re-imaged the PC, and flashed the bios with correct information. And we lived happily ever after.

As a side note, after all this I tried to upgrade this PC to Windows 10 1709 Enterprise from Windows 7 Enterprise (I will write more about this issue a different time), and it worked!