"Power to the people, Marty." Or, Lenovo please stop telling me the onboard battery has failed.

One of the most annoying problems with modern laptops is the lack of user-replaceable (or even just 'replaceable') batteries.  Current batteries will wear out after a few years.

Lenovo attempted a hybrid battery solution on their T480 laptops 3 years ago.  Lenovo had a normal swappable battery AND a built-in battery attached to the motherboard.  Unfortunately, now after 3-5 years those built-in batteries have begun to fail.

Now, the laptop still has an external battery that's replaceable so the laptops still have lots of life left in them.  But once the onboard battery is detected as 'failed' Lenovo "nagware" is activated reminding you of the fact the onboard has failed - and it does this like every 15 minutes!

In order to stop this annpyance that's ruining a perfectly good laptop experience is actually very easy.

1.) Open Computer Management.

2.) Expand System Devices.

3.) Look for the "Lenovo Power and Battery" device.

4.) Right-click and choosr "Disable device"

That's it.  It appears in both lab and production laptops this has resolved the issue.  These laptops have NO Vantage or System Update software installed.  Rhey are fresh W10-21H2 installs.

Hopefully this helps as I have struggled with this issue for almost a year.  If you experience so.ething different or have additional suggestions, comment below.

Windows 7 Home Premium SP1 remote desktop issues or "Stop looking at me!!!"

I occasionally get asked to enable Remote Desktop on a Windows 7 machine that does not normally include the feature (Home Premium). Enabling the feature is pretty straightforward and allows for easy remote management of the computer for advanced users.

Jordan Hopfner has a terrific article on his blog for enabling Remote Desktop on Windows 7 Home Premium (either 32 or 64 bit). Download the ZIP file here, extract the contents to a folder, and run the "install.cmd" file as an administrator.

This worked fine for me for almost 2 years. But recently, I began to hear about issues connecting to machines patched this way. Remote Desktop clients would connect to the machine, but would disconnect again almost immediately right before the login screen would be displayed. It seems to be related to an issue with the local session manager.

Contributor "BobX" over at Windows Seven Forums posted the solution here - uninstall the Windows patch KB2984972 - "Update for RDC 7.1 to support restricted administration logons on Windows 7 and Windows Server 2008 R2".

After following Bob's directions to uninstall the update, Remote Desktop began working again.

UPDATE: There are also reports of the Windows update KB3003743 also breaking Remote Desktop, but hat has not been my experience yet.

HP Installer Setup has stopped working or "My kingdom for a decent error message!"

I was recently called upon to install a new HP Color Laserjet M476nw at an employee's home office.  Unfortunately, after downloading the latest drivers & software from the HP website, I ran the isntaller and received one of the top 5 most annoying and generic errors of Windows 7:

"HP Installer Setup has stopped working"

Now, don't get me wrong, I appreciate that Windows didn't decide to just blue-screen and dump me to a DOS prompt, but you'd think it could provide just a _small_ amount of additional information without forcing me into the Event Logs.  After over an hour of troubleshooting, installing, reinstalling, and Googling,   I finally found the following recommendation buried here.

Go to “Control Panel”, “Programs and Features”, “Turn Windows features on or off” and mark “.NET Framework 3.5.1”.

Once I enabled the .NET framework inside Windows 7, the installer completed without errors. Hopefully this tip will save you some time.

The Best Laid Plans of Mice and DVD's

"Gee Brain, whatdya wanna do tonight?"
"The same thing we do every night Pinky, disassemble the DVD player!"

As a college student in the mid-90's, I became a huge fan of The Animaniacs - an animated comedy variety show featuring "the Warner brothers and the Warner sister, Dot" who just for fun "run around the Warner movie lot" and are "zany to the max."  While Yacko,  Wacko, and Dot were the stars, there were various other characters who each had their own sketches and stories which were only minimally connected to the stars.  One such story arc was about genetically enhanced lab rats by the names of Pinky and The Brain.

Now. I tell you all that to tell you this, my wife and I were big fans of Pinky and The Brain sketches and we actually own box sets of their shows.  Unfortunately, we lost one of those DVD's a couple of years ago while visiting family in another state.

We spent a lot of time trying to find the wayward DVD but to no avail, eventually giving up.  However, while visiting the same out-of-state family this week, I happen to see the front cover of their DVD player had broken off, leaving the disc tray exposed.  On a whim, I asked my wife to get her phone flashlight and see if she could see anything inside the DVD player.

The picture is what she saw.

Apparently, the DVD had managed to flip out of the disc tray while loading or unloading.  The missing disc had been inside the DVD player for two years - not interfering with its operation at all - and no one had noticed.

Quite an interesting story.

5.7.1 Client does not have permissions to send as this sender - or "Leeloo Dallas, MultiPass."

After my recent upgrade to Exchange 2010, I began having issues with sending out service account emails.  Usually I use distribution group addresses for FROM fields to help easily tell which system was responsible for sending emails.  For example, my AD Reports are sent out to an "AD Reports" distribution group with a SMTP FROM address of "ADReports@xxxx.com".  So this helps to keep things simple.

In Exchange 2003 (bless its heart), it wasn't set to authenticate FROM fields with any precision, so you could put just about anything in there and it would blithely send it on its way.

In Exchange 2010 however, now there's checking if a FROM field matches an object in the Exchange organization (even if it's just a distribution group).  If there's a match, the "Send As" permission will be checked and if it doesn't pass, an SMTP error "5.7.1 Client does not have permissions to send as this sender" will be generated.  This was the issue I ran into once I pointed my reporting tools to the new Exchange's SMTP server.

To fix this, you must grant the "Send As" permission to the authenticating account trying to send the email.  If you are trying to send as a different mailbox, this is a simple task.  (Right-click the mailbox, choose "Manage Send As Permissions", and adjust accordingly)  However, if you are trying to send as a Distribution Group this is trickier and requires Powershell.

The following command will allow you to grant the "Send As" permission on a Distribution Group.
"Add-ADPermission -Identity <Distribution Group> -User <User or Security Group> -ExtendedRights Send-As"


Quote explanation:  If you're wondering about the quote at the top of the article, it refers to one of my favorite movies.  "The Fifth Element" starring Bruce Willis, Gary Oldman, and a young Milla Jovovich before her Resident Evil days.  The quote is from Ms. Jovovich's character Leeloo who is an alien on Earth.  She is trying to use an ID card called a Multipass to board a spaceship.  Not knowing the language, she simply holds up her ID and continually says "Leeloo Dallas, Multipass" over and over again.  Fortunately, Bruce Willis' character arrives on the scene in time to help poor Leeloo past the ticketing agent before the authorities are called on her.

The relevancy to this article is simply that my reporting server was sending its ID to my Exchange 2010 server over and over again, expecting a different result each time.

And this is why they say if you have to explain a joke it isn't funny...

Android Gallery force closes when Share pressed, or "I'll make him a (sharing) offer he can't refuse!"

Recently, I ran into a problem on my Samsung Galaxy S3 phone's Gallery app. When I pressed the Share button, the Gallery would force close with an error "the Gallery app has closed unexpectedly."

I knew it was something recent that broke the Gallery, as it was working a couple of weeks ago. After some quick internet research, I came across a solution that fixed the issue.

Make sure the "Picture Artist" built-in app is not disabled/turned off.

Apparently something in the built-in Paper Artist app is used when Share is pressed in the Gallery. I had turned off Paper Artist last week (along with every other bloatware app I could find). As soon as I turned Paper Artist back on, I was able Share again.

Now I know, and knowing is half the battle.

Exchange Management Console login issue with quota request exceeded - or "I'm giving her all (the Kerberos requests) she's got, Captain!"

I've been having issues with some of my Exchange servers being unable to open the Exchange Management Console.  When attempting to make the initial connection to the Exchange Management service on the specified server the following error is given:

The following error occurred while attempting to connect to the specified Exchange server 'xxxxx':
The attempt to connect to <server FQDN>/Powershell using "Kerberos" authentication failed:  Connecting to remote server failed with the following error message : The WS-Management service cannot process the request.  The system load quota of 1000 requests per 2 seconds has been exceeded.  Send future requests at a slower rate or raise the system quota.  The next request from this user will not be approved for at least 124275504 milliseconds.

Thanks to Jason Shave for his elegantly simple solution to this convuluted error:

The server had recently received a new SSL certificate using the Exchange 2010 certificate provisioning and assignment process in the GUI. Unfortunately the IIS service hadn't been restarted yet and the URL used for remote PowerShell was using a certificate which wasn't trusted or valid anymore.

A quick "IISRESET" on the server resulted in my fix.

You can see Jason's original post here regarding this issue.

Review: "Megamind" (theatrical)

So you finally take control of the world.  Now what?

This question is the focus of the second act of Dreamworks' newest animated feature, "Megamind".  The movie deals with the adventures of the azure-skinned and over-size noggin'ed supervillain Megamind (voiced by Will Farrell), his superhero foil Metro Man (voiced by Brad Pitt), and the shared love interest Roxanne Ritchi (Tina Fey).  Megamind is assisted in his endeavours by his aquatic minion, Minion (David Cross).

The movie is a satire of the typical superhero movie.  In this movie, the supervillain tells the story from his often-abused point-of-view as he's defeated time and again.  Without revealing too much of the plot, Megamind does finally get what he wants but finds out that just because you have everything doesn't mean you have everything.

Some of the funniest moments are provided by Megamind's problems with the English phonetics - "me-trah-si-tee" is often used for Metro City.  Will Farrell does an excellent job as the voice of Megamind.  Tina Fey's performance as the non-damsel-in-distress Roxanne is hilarious during her opening repartee with Megamind.  Overall, the dialogue is really smart and well-delivered.

Where the movie really shines for adults though is the musical score - heavy on late 80's rock from AC/DC, Guns n Roses, and Michael Jackson - and the choreography of the numbers.  We often found ourselves tapping our feet to the montages.

Overall, the movie is great clean fun for adults and children, particularly fans of the superhero genre.  There's a good message about discovering who you are and following your destiny.  There is no language.  There is an amount of over-the-top superhero violence though which should be avoided for extremely small children.

Highly recommended - 4.5 out of 5

Down-under Terminal Server connection woes 4 - or "You must *feel* the Force (packets) flowing through you!"

(The following is meant as humor, but it does describe the solution to this issue.)

While I was working on the terminal server issues described previously, I checked the Netgear DEVG2020 router the ISP had provided to us.  I have to say, the Netgear DEVG2020 is probably one of the most functional routers ever designed...

"What?  I can't say that?  Not passing packets on multiple connections, huh?  It was causing the terminal server multiple connection issue?  Really?  Well, OK, let me try it again."

The Netgear DEVG2020.  The router you need for security & performance...

"Not that either?  Multiple VPN connections were being blocked as well?  Oh, all multiple connections of certain types?  Issues with business applications as well?  Well..."

The Netgear DEVG2020.  A router based on industry standards for internet connectivity and....

"Again, really?!  Yeah, it has a customized firmware specific to each ISP?  Completely unsuitable for business-critical internet access?  Replaced as quickly as possible, huh?  OK."

I'm sorry, it looks like I won't be writing a review for the Netgear DEVG2020 this week as it was apparently the cause of almost every networking issue I've seen for the past few weeks.  It was replaced this past weekend by the ISP and all previously discussed issues have been fixed:

1. Unable to connect to the terminal server twice in a row
2. Unable to connect to the VPN twice in a row
3. Extremely slow Windows desktop logins
4. Business application connection issues

This explains why Microsoft was unable to see the packets for the second connections in the NetMon traces.  Turns out it wasn't Sonicwall blocking the packets, it was the Netgear DEVG2020 that was dropping the connections.

Doing more internet research, it appears there are many cases of issues with this specific router from various ISP's globally.  So the moral of the story is folks, if you happen to own a Netgear DEVG2020 router somewhere in your wide-area network, you may want to consider replacing it if at all possible.

"What a piece of junk!" - Netgear DEVG2020

'Unable To Upgrade Account' or "That depends on your definition of 'Unregistered', Senator."

I've had some issues lately with Samsung Galaxy devices not playing nice with my MobileIron system.  When trying to setup the email account, the devices throw up a "Unable to upgrade account" error.  This started a few weeks ago and affected both new or existing Samsung Galaxy devices (S4, Note, Tab, etc.)

After spending time with support from Samsung & MobileIron, it turns out there's a setting inside MobileIron that blocks unregistered devices (devices without MobileIron) from setting up an email account - 'Auto Block Unregistered (unlinked) Devices:'

By turning this setting ON, MobileIron was actually blocking the Samsung devices from connecting for their email account because they were not yet 'linked' to an account.  It was being 'too' secure.

So, if you see "Unable to upgrade account" on your Samsung Galaxy device (possibly other Android device models), and you use MobileIron, you should check the 'Auto block unregistered (unlinked) devices' setting is OFF under the VSP : Sentry : Preferences.

Down-under Terminal Server connection woes 3 - or "I left my (packet) back in San Francisco"

Microsoft came back with an update after examining network traces from the client and the server.  Seems the initial 'scaling' connection works fine but when a second connection is attempted, it fails with no explanation.  The Wireshark trace was inconclusive so a NetMon trace was created and sent to Microsoft for analysis.

The NetMon packet trace confirmed what I already suspected, the client packets were not making it to the server (duh?).  Microsoft recommends taking a workstation outside the firewall and testing.  This would eliminate the firewall from the potential issues.

Sonicwall came back and recommended we change the VPN connection timeout (TCP & UDP) on the firewall.  This of course, had no effect as it is not the VPN connection having the issue.  The workstations in Australia can access the rest of the network fine.  It's just when they try to make a second connection to the terminal server that things go south.

The idea I'm floating around right now is this may have nothing to do with the Sonicwall after all, it could be related to the gateway device at this location provided by the ISP.  It has firewall capabilities and may be causing an issue with the Sonicwall.

I need a user connect to the wireless on the gateway device (thereby eliminating the firewall from the equation) and see if he is able to work correctly.  This would seem to point back to the firewall being an issue - unless the wireless side of the gateway doesn't go through the same processing as the LAN side of the gateway, where the Sonicwall is.

Things are continuing to develop - unfortunately the picture isn't any clearer...

(to be continued....)

Down-under Terminal Server connection woes 2 - or "What's love (of encryption) got to do with it?"

What's in a name?  What's in a service pack?  Two (almost) identical questions when it comes to the world of Microsoft - for all Microsoft updates are not the same.

In my testing of the Windows 2008 R2 SP1 terminal server issue described in the previous post, it came upon me to test to a different terminal server - but one still located in the same subnet as the problematic one.  This revealed something very interesting.

If I used a Windows 2008 R2 (base) terminal server, I could not re-produce the issue from the same client that I was getting with Windows 2008 R2 SP1.

So, this puts us back to a very interesting question then.  What is it about the SP1 install that causes our client to only be able to connect once and only once?  This was the question that I was going to have to resolve.

(to be continued again...)

Down-under Terminal Server connection woes - or "Throw another protocol error on the Barbie!"

Recently, I've had to deal with a rather bizarre terminal server issue.  At this one location, no computer could connect to a specific terminal server twice.  The computers could connect fine one time.  But, if the user logged off or disconnected, and then tried to connect to the terminal server again, the following error was displayed each time:

Your Remote Desktop sessions has ended.  The connection to the remote computer was lost, possibly due to network connectivity problems.  Try connecting to the remote computer again.  If the problem continues, contact your network administrator or technical support

Of course, you would think 'orphaned session' or a terminal server setting, but that was not the case.  No limits were set and I could see the users' sessions disconnecting just fine from the server.  The first connection would work fine until the user logged off the terminal server or was disconnected.  Once that happened, the user could not sign in again with the above error.

But here's the trick:  If I rebooted the server or the firewall at the location, the users could connect again - but again, only once, then another reboot would be required.

So after confirming the usual suspects like DNS, AD account status, and VPN tunnels were all active and working normally, I decided the issue had to be something deeper.  I found the following error in the Terminal Server's System Event Log:

"Event 56, TermDD - The Terminal Server security layer detected an error in the protocol stream and has disconnected the client."

This little Event ID led down a real rabbit-hole of blog posts, forum discussions, and random Microsoft KB articles.  Let me give you some of the highlights:

• Reduce the encryption level of the terminal server to Low & use "RDP Encryption"
• Set the RDP encryption algorithm to balance network & memory usage
• Enable 'keep alive' on the terminal server
• Disable TCP Chimney Offload, Receive-Side Scaling State (RSS), and NetDMA
• Confirm RDC client version is the latest on all clients
• Use "ERR.EXE" to analyze the last word byte of the above error (B50000D0 in this case)

No one online seemed to have the final solution and none of the suggestions helped me.  I put everything back the way it was, pulled my head away from the wall, and decided to just get down and dirty with a Wireshark trace.  Hopefully the trace would help figure out exactly what was happening with these failed connections.  Running a quick client trace gave me some errors but nothing definite.  Wireshark did report some checksum errors and this "dissector bug":

"Dissector bug, protocol T.124 proto.c:3478 failed assertion (guint)hfindex < gpa_hfinfo.len) unregistered hf!"

The checksum errors led me down the hardware stack to the network cards, turning off the "checksum offload" at the IP & TCP levels on the virtual host & virtual server.  This cleared up some of the Checksum errors in Wireshark but still the same terminal server error persisted.

I was still not convinced that the Sonicwall at the location wasn't to blame for all this.  After all, we had other network issues with a business application at that same location which had still not been fixed.

Bruised and beaten, I elected to open support tickets with Sonicwall and Microsoft and begin working this issue from each end with them....

(To be continued...)

Ramblings of a (IT) madman

I started this blog with the intent of documenting the crazy issues I deal with on a semi-regular basis for the betterment of mankind - or at least the internet.  Often these issues have no readily available solution via internet search engine and so placing them here serves a dual purpose as a repository of data for myself and a small contribution to the sum total of all mankind's knowledge that is Google.

Please feel free to comment as you will.  I don't promise an answer.  I actually don't even promise to read the comments on a regular basis.  Under-promise & Over-deliver, amiright?  But if you feel the need to add something please do so.


...And now, for the blog's legal disclaimer (as previously recommended by the law firm, Doowey, Cheatham, and Howe).  Nothing on this blog should/would/shall be endorsed by any employer of mine at any point in time -past, present, or future (sorry Google).  The problems discussed herein are random events that I may or may not have hallucinated I was involved with.  All information contained in this blog is my own personal experience and should not be construed to have constructive value whatsoever to your specific issue.    Everything on this blog is 'at your own risk'.  I will not be responsible for any inconsequential damages, incidental damages, or deliberate damages from taking my advice.  All comments on this blog are the sole property of their owner, go talk to them if you disagree with what they are saying.  This blog will not self-destruct but the information contained herein is guaranteed to have a 7-year shelf life from date of posting - thanks for that, Microsoft!