Update 14/03/14: According to Microsoft, this problem is fixed in the March 2014 Cumulative security update for Internet Explorer. However, I was able to immediately reproduce the problem even after the update was installed, so the below still applies as far as I’m concerned.
As my former boss Bond once said, “If you’re going to live on the cutting edge, you’ve got to expect some blood”. One of the many joys of being an early adopter is finding stupid bugs before everyone else, and so as I began wide-scale testing of Windows 8.1 at my school, we found this one.
In a nutshell, pretty much every time we tried to load www.google.com in Internet Explorer 11, we got a “This page can’t be displayed” message, yet the site would inexplicably load fine just by clicking refresh. We saw the same with other Google sites such as Gmail and Google Drive – but most sites seemed immune. Both the desktop and Modern UI versions of IE were affected.
Like most schools, our web access goes via an HTTP proxy so that content not suitable for the 5 year-old cherubs can be filtered out. We use Smoothwall, which is one of the better filtering products out there, but so many applications are not designed with proxy support in mind that it does occasionally cause problems. It’s very rare for any mainstream browser to have a problem with proxies, but when I bypassed it, the problem immediately went away. What was more curious was that we were already running Internet Explorer 11 on our Windows 7 workstations too, and they didn’t have any problems.
I know the Sound Recorder program in Windows 7 isn’t something you probably spent much time on, but here’s a tip: flooding the Event log with 18 messages per second due to an invalid pointer exception you couldn’t be bothered to handle properly is not very helpful when I’m trying to troubleshoot.
Please learn to use exception handling properly, and while you’re at it, build in a counter check to make sure you aren’t writing 79,000 messages to the event log in a single session.
Love and kisses,
Office 2013 error: “Sorry, we are having some temporary server issues” – fix it by clearing a key in the registry
Update 27/02/14: Microsoft have released Service Pack 1 for Office 2013, and still does not contain a fix for the below issue.
Recently we began using Office 365 accounts with the Office 2013 desktop suite, and during a roll-out session for staff, almost everyone in the room got this error message when trying to load the sign-in screen for their Office 365 account for the first time:
The error occurred even before asking for any login details, and a quick check of our Internet access logs revealed that Word wasn’t even attempting to contact a server. I hadn’t seen this during testing, and we couldn’t work past the error when we encountered it, so the roll-out session was a bust. To say I was irritated is somewhat of an understatement.
Stop sending your stupid Pages files to people via email.
Some of us use computers for actual work and not just dicking around, so we have Windows computers. Even those die-hard Mac users who actually do work on them tend to install OpenOffice or buy Office for Mac, rather than use iWork.
I’m tired of trying to convert your documents for you because our staff have no idea what to do with them, so either sort your Mac out with a proper office suite or BUY A REAL COMPUTER.
Love and kisses,
Shortly after upgrading to Outlook 2013 from Outlook 2010, one of my users complained that some of his emails were showing up with invisible text in the message body. He knew there was text there, because he could highlight the invisible text and copy & paste it into Word.
I quickly determined that it was only plain text emails that were affected (rather than those with HTML or Rich Text formatting), which led me to investigate the font options. Sure enough, somehow the font option for reading and composing plain text emails had been set to a white font.
You find this option by going to File > Options > Mail > Stationery and Fonts, then clicking the Font button under Composing and reading plain text messages.
The font colour should normally be set to Automatic, and in our case it was inexplicably set to white. Setting it back to Automatic immediately solved the problem.
Bizarrely, even though the Font color was set to white (as shown in the above screenshot), you can see that this was not reflected in the preview on either the Font dialog or the preceding Signatures and Stationery dialog. I’m also 99% sure the user didn’t change this himself, since the aggravation it was causing him far outweighed the value of doing it to wind me up.
“Why is this remote restart taking so long?” I wondered, watching a successive stream of Request timed out messages being returned from PING.
One long walk to the server room later…
Say what you want about Windows, but Windows Server doesn’t spontaneously decide to do a disk check during restart.
In today’s edition of “Stupid Error Messages from Exchange”, we have this gem of idiocy from the Exchange 2010 Management Console:
Yes, Yes to All, No or Cancel. But… Yes to what? Am I saying, “yes, I want to continue,” or perhaps, “yes, I agree that is a silly idea so don’t continue?” Am I suddenly in the middle of an MCSE exam and have to decide whether this is the expected behaviour or not?
ASK ME A BLOODY QUESTION IF YOU WANT A YES/NO ANSWER.