This was a weird one.

Ever since we started rolling out Windows 10 to our clients we'd get scattered reports from users of their mapped drives not working properly. Users are set to map various drives based on their security groups when they logon via a login script. Sometimes the drives would map, sometimes they wouldn't, sometimes some would, some wouldn't etc. But usually if they waited awhile, logged off and on again it would be fine. It appeared to be completely random.

Because it was so random it wasn't on the top of the priority list for figuring out. But as the Windows 10 install based grew it became more and more of an issue.

After much head scratching we finally stumbled across the answer. Early suspicions that it had to do with UNC hardening were correct. Back in 2015 Microsoft released two fixes - MS15-011 and MS15-014 - which dealt with hardening access to the SYSVOL and Netlogon shares as well as Group Policy processing. Searching the internet returned numerous articles detailing the exact problem we were experiencing, but in each case the 'solution' was to disable this hardening. So the problem would go away, but your system would remain vulnerable to the various attacks these fixes were designed to stop.

Finally we found came across a single article on Reddit that made the correct association with the proper fix.

We've upgraded our domain/forest level over the years from 2003 to 2008R2 to 2012 and most recently to 2012R2. In each case nothing in either the upgrade process nor the associated how to guides mentioned anything about replacing the File Replication System (FRS) with the newer Distributed File System Replication (DFRS). Apparently the latest version of Windows Server doesn't support FRS anymore. One can only wonder if at that point during the upgrade it would finally flag it as being an issue and advise you to upgrade.

In any case, I followed the steps from Microsoft to migrate from FRS to DFRS on our Domain, with DFRS being touted as more reliable, stable, efficient and so on. And as that one single person on that one single Reddit article pointed out - that was the missing piece! We now no longer have the mapped drives issue and didn't have to disable UNC hardening to 'fix' it.

Another day, another adventure with Java. I had a server that over time with multiple installs and uninstalls of Java ended up getting messed up.

Although the previous version had been uninstalled, when you went to install the latest version after getting the initial splash screen it would disappear and when you'd check Add/Remove Programs it wouldn't be listed. Even though there were no error messages during the install I figured that at some point a previous uninstall didn't happen cleanly.

Ok, so how to manually remove Java? I did some Googling and came across a helpful article detailing how to do exactly that.

I didn't bother mucking about with all the instructions for manually editing the registry, instead I downloaded and ran the recommended Microsoft utility. It asked me if the issue I was having was related to uninstalling or installing. I told it uninstalling and after a few seconds it popped up with a previous Java version asking me to confirm that was the product I was trying to get rid of. After affirming that it was it went and removed all the remaining (mostly) remnants.

I say mostly because I noticed in the Control Panel that the Java icon was still there - however instead of the familiar logo it was blank. So off to do some more searching. Finally I came across this article and sure enough it removed the corrupted icon entry. I thought creating a shortcut for the Control Panel icon and then clicking on Change Icon was a pretty neat way of determining the old install path.

Once that was done I ran the latest version installer and it installed just fine.

Working in a predominantly Windows only shop my experience with Linux is limited to say the least. However we recently added a few servers running SUSE Enterprise Linux and I was tasked with figuring out how to backup the database on them.

Thankfully the backup suite we use - EMC Networker - has a Linux client. I just had to figure out how to install it. Linux has definately come a long way from the days when I first mucked about with a Red Hat distro having to scour through man pages trying to figure out how things worked. I'm most familiar with Linux Mint, but SUSE isn't that much different at least when comparing the graphical interfaces.

First up I downloaded the Linux client from EMC's support site. Although it was a generic Linux installer it appeared that I wouldn't have to recompile it for SUSE. The download came in a TAR format. Double clicking on it brought up the YAST installer interface but then listed a number of dependencies I'd have to individual locate, download and install. My initial reaction was that this was going to be a pain.

Then I did some Googling and found out that there's a command line utility called Zypper which will extract the contents and auto-download and install any dependencies. So I gave that a try and sure enough it worked as promised. From there I just had to start the required services. I now had the client installed.

Then it was a simple matter of setting up and configuring the client in the Networker Admin gui. Running the client wizard brought up the list of directories and files. I specified the contents I wanted and closed out the wizard. Then as I would do for any Windows client, I setup the backup group, schedule, media pool etc.

Once all that was done I kicked off a backup and was relieved to see it working.

Reading the documentation, the only downside to the Linux client is that unlike with it's Windows counterpart, there is no restore GUI. Everything is done via command line. After all, it wouldn't be the real Linux experience without at least some command line interaction.

Recently I was given two new Dell laptop models - a Latitude 5491 and 5591 to evaluate and add to our list of supported models for our imaging software which is Microsoft's Deployment Toolkit (MDT).

As with previous systems I went about downloading all of the required drivers from Dell's premier support site, creating new categories in MDT, and importing the drivers into it. Once all that was done I PXE booted the laptop in question and brought up the Lite Touch Wizard. However for some reason the mouse wouldn't work and the cursor was missing.

I did notice while I was downloading the drivers that there was an updated driver for the laptop's Touchpad so I figured I just needed to inject it into the boot image and I'd be good to go. So I followed the usual instructions and injected the driver, PXE booted again - and still no mouse movement.

Injecting Drivers Into Boot Image

So off to Google I went and did a bunch of searching to see if anyone else had experienced this issue. Eventually I came across one article and found out that in addition to the Touchpad driver I also needed to inject some new driver I've never seen before - the Intel Serial IO Driver.

So once again I mounted the boot image, injected the serial drivers, and unmounted the image. Went back and PXE booted the laptop for the 3rd time and...success! I once again had a cursor. While I obviously could have still navigated around using just the keyboard and the Tab key it's just so much easier being able to use the mouse.

Currently in the midst of upgrading our clients to Windows 10 using SCCM as the method of deployment. One thing we noticed is that after the upgrade is complete the client is let there sitting at a privacy settings splash screen.

As we don't want the end users picking settings at random or calling the Help Desk wondering what they should do we needed to find a way of suppressing the screen.

Searching online I found numerous suggestions all involving making a change in the registry. Most mentioned the PrivacyConsentStatus key, but in our testing we found that one added key was not enough to suppress the screen.

Registry Settings

Finally I came across a post that listed all the required keys that need to be added.

Once they were added and saved as a .reg file I was then able to add the additional command in the Task Sequence to import the registry file. Now after the upgrade is complete the user is no longer prompted to set all the required privacy settings.

A few days ago, as part of our efforts to roll out the latest build (1803) of Windows 10 to the company, I went and downloaded the latest Administrative Templates for Group Policy. After downloaded I extracted and dumped the .admx and .adml files into the Central Store - the same as I've down countless times in the past.

However a few days ago it was discovered that whenever you'd go and try to modify an existing group policy it'd pop up with an error message: "Policy presentation element 'Estonian' in referenced presentation 'SelectOCRLangs' does not exist...".

Er, say what? 

After doing a bunch of Googling on this error, it turns out that when Microsoft released the latest template files, they forgot to update the SearchOCR.admx file. So the error is basically complaining of a mismatch between it and the language file. Really Microsoft?

A bunch of the 'solutions' involved either deleting the file outright or opening up the .adml file in notepad and adding this additional line:

<string id="Win7Only">Microsoft Windows 7 or later</string>

But as someone else pointed out that to properly fix the issue, you'd have to do that for every language file which frankly would be a pain in the rear end. Eventually I came across a post with the preferred solution.

Find a system running a Windows 10 build later than 1603, go into Control Panel, Programs, Turn Windows features on or off, and if not already turned on, enable 'Windows TIFF IFilter'. Then search for the SearchOCR.admx file on that system and once found, simply copy it into the PolicyDefinitions folder of the central store.

SearchOCR.admx Location

This will ensure that you have a matching version between the .adml and .admx files. After making the changes I was able to open up any group policy in the editor and there was no more error message.

It boggles my mind that something like this got past the quality control (is there any more quality control at Microsoft?) people. Until the next time Microsoft screws up their own product...

Recently we had a server failure and I needed to connect to the remote access card (iDRAC) that was installed on the server. Basically it allows you to connect to a server even when the server is offline due to a power outage, hardware failure etc. It uses a web interface to display all the information and also gives you a tiny thumbnail of what is being displayed on the screen. But to be really useful you need to fire up the console which is a full screen rendering and much more friendlier to work with.

The console is Java based and has always been somewhat of an adventure to get working between MS updates, Java updates, and the various browser updates.

Recently I upgraded Java on my system to the latest version and it appears that version in the interest of security has disabled one of the encryption algorithms - Triple DES? SSLv3??

Whatever the algorithm is, the iDRAC console will not run without it enabled.

After futzing with it for awhile trying to get it to work I came across an article while searching Google that while not solving the problem, put me on the right path. It mentioned modifying the java.security file. When I compared that file on a system with the latest Java to a system with the earlier version of Java I noticed and additional entry on the upgraded system.  In the end this is what I had to do to resolve the problem:

• Go to C:\Program Files (x86)\Java\jre1.8.0_171\lib\security
• Edit the java.security file
• Search for jdk.tls.disabledAlgorithms
• At the end of the string, simply remove this portion: ‘, 3DES_EDE_CBC’ and save the file

Java Security File

After making that change everything was working again and I was able to run the console and proceed with working on the failed server.

Note: You still will need to add the iDRAC URL into the Java Security Exception Site List. And of course get through the plethora of security dialog prompts. Aren't web based applications awesome??

At the beginning of the month it was announced that Oppo would stop making Blu-ray players. A collective gasp from physical media aficionados the world over was let out. Oppo was one of the few remaining companies left dedicated to creating quality devices.

While I've been perfectly content with my Pioneer player, I knew at some point I'd have to go with someone else - likely when (and hopefully not for many years) my Plasma dies. I had always assumed that I'd get an Oppo to replace it.

Sadly, Blu-ray is now truly a niche product and if you want something other than the commoditized garbage being sold these days your choices are now limited to just a few high end offerings.

So within a day of the news I panic bought their top of the line UDP-205. It likely was the last new player left in Canada and days later it was sold out everywhere. I justified it as I'd now have a spare player and as mentioned if I eventually get a new TV, which would be a 4k model, it would allow me to play 4k titles. It's also their audiophile model, so if my beloved SACD player ever died it would make a good substitute for it as well.

Another feature it has - once you install a modification kit - is the ability to be region free. Blu-rays are coded with 3 different regions. North American is Region A, Europe Region B, Asia is Region C. Normally any disc you buy is going to be the correct region for where you live, but sometimes people will buy discs from other countries because they might have different features, better quality etc.

Or if you're like me, you might not pay attention when buying something off Amazon and get a European disc by mistake. Several months ago I was somewhat annoyed to find that The Last Seduction wouldn't play in my player as it was Region B.

Once I had my new Oppo I ordered a region free kit for it from Bluraychip.dk. Unlike some other kits that involve overwriting the player's firmware, this one is a physical device you install into a 4-pin connector on the player's circuitboard. The downside is you have to rip apart your player - and unlike Oppo's cheaper UPD-203 player, on the 205 you have to remove 3 circuit boards in the process. Not for the faint of heart considering how expensive it is. But I took my time and other than fussing with a couple of ribbon cables which are always fragile I was able to get it installed and get everything put back together without too much effort.

I followed the instructions which consisted of a sequence of key presses on the remote to set the appropriate Region code, popped in my Last Seduction disc and it came up just fine. I cracked a beer, sat back, and watched some mid-90's noir goodness.

Recently I was in the SCCM Console and I noticed that the last Software Updates synchronization attempt had failed.

I checked the Component Status and sure enough WSUS was showing errors. I looked at the messages and there were a bunch listed - 'WSUS Synchronization Failed. WSUS server not configured', 'HTTP Error 503. The service is unavailable.' and so on. I checked and the service was definitely running, so that wasn't the problem. I then went into IIS Manager and noticed that the WsusPool Application Pool was in a stopped state. So I restarted it.

Application Pool Settings

I then tried to initiate another synch and after awhile it again failed and once again the Application Pool was stopped. At this point I went to Google and found numerous posts related to this issue. In almost every article they mentioned going into the Advanced Settings for the pool and bumping up the Private Memory Limit from the default to 4GB or even 8GB and then restarting the pool.

Even setting it at 8GB didn't resolve the issue however. It was at this point I broke out Task Manager and watched the memory usage of the w3wp.exe process after the pool was restarted. Sure enough it just went over 8GB. So I then found an article that said by setting the value to 0 you would allow it to use as much memory as it needed.

After doing that Synchronization was once again working!

Originally I had a 32" Sony TV in the garage which was the smallest TV you could get that would still output 1080p. It was fine, but the sound it produced was pathetic as are most flat panel televisions.

So I ended up replacing it with a larger 40" Sony KDL-40W700C model and with the larger size the speaker output was increased correspondingly. For the most part I was happy with how it sounded as it was mostly just TV shows I was watching.

Ever since we got the basement home theatre done my beloved Laserdisc player had been sitting neglected in a corner of the media room. There simply wasn't room in the media rack for it. So eventually I decided I would just hook it up to the garage TV whenever I felt the urge to spin up a disc. I bought a composite to HDMI adapter and was able to once again watch my LD's.

But again, the sound was horrible. I had to almost max out the volume to listen to movies at anything approaching what I was used to. After much thought I decided to bite the bullet and buy a soundbar. As I already had a Sonos system I went with their Playbar product which had really good reviews.

There wasn't much to the packaging. Just a quick setup guide, manual, power cord, optical cord and the speaker itself. The included optical cable looked pretty thin so I went with my own optical cable. That was a mistake. After taking the TV off the wall and hooking everything up I was unable to get the TV back on the wall. After much fussing with it I realized it was because the optical cable stuck out to far from the TV. I then looked at the included cable again and saw that it's connector was much shorter (almost like they had planned it that way). Once I swapped it in things went much better. I also had bought the mounting bracket which was a separate product. It came with a template and I measured everything out, affixed it to the wall, made sure it was level, punched my pilot holes, installed the included anchors and screwed it in nice and tight. The speaker easily slid into place and everything was mounted.

Then it was just a matter of setting the audio output on the TV to 'Audio System', firing up the Sonos app, discovering and synching with the Playbar. It then went and presumably upgraded the speaker firmware and had me press a few buttons on the remote to learn the correct codes to use for controlling the volume (you can also manually adjust the volume on the side of the speaker). Last step was to then run the audio calibration which it suggested I do. That consisted of me walking around the garage moving my iPad up and down while it produced various test tones.

I still haven't hooked up my LD player to watch a movie, but I rented a movie on iTunes and played it over my Apple TV and it sounded terrific. I then proceeded to listen to some XM radio until early in the morning.

All in all I'm quite pleased with this purchase. It looks and sounds great!

Recently I upgraded our SCCM site server from Windows 2012 R2 to Windows Server 2016. This was done as 2016 is needed in order to support Surface driver updates via SCCM. Overall the process was fairly straightforward, however there were a couple glitches of note.

First up was a warning that popped up during the install. It was complaining that the VMWare video driver wasn't compatible. Obviously the site server was running as a VM. Our VMWare environment is ESXi 5.5 and I had previously verified that 2016 was a supported guest OS. I decided to forge ahead despite the warning and 2016 installed fine, however after reboot it was using the generic basic display driver.

I did some quick Googling and didn't find a lot on this issue, but finally I came across a post on a thread that suggested doing the following:

1. In Device Manager, uninstall the Display Adapter

2. Reinstall VMWare Tools (repair)

3. Reboot

Video Driver Issue

After the reboot it was once again using the VMWare driver.

Second issue I noticed was that anyone using the SCCM Console remotely would fail to connect. Running the console locally on the server worked fine. Some more Googling ensued and eventually I stumbled across the solution:

To fix this, on the site server launch wmimgmt.msc console, then bring up the local computer's properties and Security tab. Then browse to root / SMS and root / SMS / site_[site name]. Add the SMS Admins local group back to both of these, and make sure they have Execute Methods, Provider Write, Enable Account, and Remote Enable allowed.

After making those changes I was able to connect once again. Overall I'm pleasantly surprised at how well the upgrade went.