Office 2013 error: “Sorry, we are having some temporary server issues” – fix it by clearing a key in the registry
Updated 11 June: In the original version of this article, I recommended uninstalling update KB2768349 (along with the updates it superseded) to fix this issue. This turned out to be only a temporary workaround, and there is a much better workaround detailed below.
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.
Last summer, I started using Microsoft System Center Essentials 2010, primarily for its software distribution functions. Aimed at small- to medium-sized networks, it’s ideally placed for use in school. Like almost every System Center product I’ve used, it wasn’t the simplest thing in the world to set up, but once working, it works reasonably well.
Well, except for…
On Thursday, Microsoft release ‘Wave 4′ of Windows Live Essentials, otherwise known as the 2011 version. Though primarily aimed at home users, there are a couple of applications that are great for schools, particularly Windows Live Movie Maker. There are a couple of gotcha’s: first, only Vista and Windows 7 are supported in the latest version, and a lot of schools are either too scared or too poor to upgrade from XP. Secondly, it’s not the easiest bundle of application to deploy over the network.
This is a technical article which is light on judgemental ranting, so try to keep up.
I hate the grammar checker in Word. It’s a horrible piece of technology that is riddled with inaccuracies.
Call me a pedant, but I wouldn’t want to ship a product that only half works. When a grammar checker can read the sentence
“Chocolate don’t make you fat.”
and claim that there is nothing wrong with this grammatically, there is something very wrong. Word has done this in every version since the grammar check was introduced, and still does it in Word 2010. I’d be embarrassed by this if I were on the development team. On a personal level, I am also dangerously irritated by the fact that it frequently spits out a ‘semicolon use’ message whenever I (correctly) use a semicolon in a way it can’t quite understand.
I get that natural language grammar rules are complicated to automate, partly because they have so many exceptions. Spelling is easy because each word is treated in isolation. Education observers have decried the rise of the spell-checker as a catalyst for the decline of pupils’ personal abilities to spell correctly, despite the fact that I can personally attest to the fact that much of the spell-checkers job is checking for poor typing, not poor spelling. However, none to my knowledge have examined the fact that pupils relying on the grammar checker as a crutch may not only be unable to form sentences themselves, but will go around believing such monstrous constructions as the one above to be correct. At least by relying on a spell-check, the end result is still correct spelling.
Last week I decided to add System Center Essentials (SCE) to my network, having decided a little while ago that the full System Center Configuration Manager and its associated sister products were slightly overkill for my network. This opinion was not helped by the fact that a 3-day attempt to get System Center Configuration Manager 2007 installed a few years ago resulted in nothing more than a near mental breakdown and 3 days of my life wasted that I will never get back. So, SCE seemed like it might be a less stressful choice.
Like hell it was.
Little did I know that within minutes, trying to install this on my WSUS server (since SCE cannot be on a different server from WSUS) would fail dismally when it tried to move the WSUS database from the Windows Internal Database system to a proper SQL Server instance:
13:10:36:CreateShareForBackup: Failed to create the share for the WSUS backup.: Threw Exception.Type: Microsoft.SystemCenter.Essentials.Configuration.Common.EssentialsShareException, Exception Error Code: 0x80131500, Exception.Message: Failed to create the share.
13:10:37:StackTrace: at Microsoft.SystemCenter.Essentials.Configuration.Common.ReadOnlyTemporaryShare..ctor(String shareName) at Microsoft.SystemCenter.Essentials.SetupFramework.HelperClasses.MoveUpdateServicesDatabase.CreateShareForBackup.Execute(MoveUpdateServicesDatabaseItem item)
13:10:37:SystemCenterEssentialsPreinstallProcessor: SUSDB move failed.
13:10:37:ProcessInstalls: Running the PreprocessDelegate for SCE failed.... This is a fatal item. Setting rollback.
That log snippet very quickly led me to a post titled “Upgrade from WSUS to SCE 2010 fails, Cannot move WSUS DB“. The process by which the author arrived at this error was slightly different, but the resolution was the same. Despite that last line talking about a rollback, the installer doesn’t completely undo all of the actions it’s performed up to this point. If you want to try again, you have to remove the sceWsusBackupShare yourself. In fact, there is so much that doesn’t get rolled back that the developers added a tool to the System Center Essentials 2010 Resource Kit called Essentials Server Cleanup Tool, which apparently does the job that the hopelessly installer always should have.
Of course, doing this is no guarantee the damned thing will then work the second time around. My install failed again almost immediately, again while trying to move the WSUS database onto an SQL Server instance. This time the logs only spoke cryptically of a server timeout.
“Sod this for a game of soldiers,” I thought. I knew how to perform this migration myself, having several times consulted the TechNet documentation on Migrating from Windows Internal Database to SQL Server. I tried the procedure, only to be denied because something was locking the database open. Suspecting that once again the SCE installer had not relinquished its vice-like grip on the system. I rebooted, and was met with success the second time around.
Once done, the SCE installer continued unabated, and everything ran smoothly.
Well, apart from this about 20 minutes later:
- Exchange 2010 MP Reports – fail on not properly designed OpsMgr installation
- Failed to store data in the Data Warehouse. Cannot resolve the collation conflict between “SQL_Latin1_General_CP1_CI_AS” and “Latin1_General_CI_AS” in the equal to operation
I suppose I should count myself lucky that I spotted this early and was still at a point where a reinstall was even remotely palatable. However, it didn’t help dismiss my consistent opinion that most of System Center is too damned complicated for its own good – especially when all I really wanted from it is the ability to be able to deploy .exe files, since the Microsoft Office team decided they were too good for GPO deployment ever since 2007…
It is a little known fact that Windows Server Update Services counts in a similar fashion, only it uses a much simpler system with only two numbers: Some and Many.
Observe this amazing numerical system in action:
Log Name: Application
Source: Windows Server Update Services
Date: 05/08/2010 12:50:30
Event ID: 13021
Task Category: 6
Some client computers are not reporting their inventory. 1 have been detected so far.
Log Name: Application
Source: Windows Server Update Services
Date: 05/08/2010 14:30:36
Event ID: 13022
Task Category: 6
Many client computers are not reporting their inventory. 2 have been detected so far.
This is why whenever I look at the Role Health Summary page, I get a dirty great red × next to WSUS; apparently just two computers not checking in counts as ‘many’.
So, if someone would someone please teach the WSUS developers how to count higher than 2, I would be very grateful.
One of the advertised benefits to schools of upgrading to Windows 7 has been the improved power management, which when used correctly, will decrease the power usage of computers throughout the school estate. But how is that actually achieved? A lot of people, myself included, assumed that the bulk of the savings would come from better Group Policy support to implement power saving schedules, such as transitioning to Sleep mode after a set time.
While that does help, there are significant benefits even without power management schedules. Simply put, Windows 7 uses less power. I measured the power usage of two computers; identical hardware, but with different software. One ran an RM CC3 build using Windows XP, the other ran Windows 7. Both machines were production workstations with all the normal software I install on them, and they were tested while idling at the logon screen. The machines themselves were 2009 Dell OptiPlex 360 workstations, and the power usage was measured using an in-line mains meter. I did not measure the monitor power usage.
Here’s what I found:
|Windows XP (CC3)||55.0 W||41.1 W|
|Windows 7||45.0 W||1.7 W|
There are two lessons here: firstly, Windows XP is shockingly bad in sleep mode. Given that XP came out in 2001, this shouldn’t be entirely surprising, but I was still astonished by how high the power usage remained even when the machine was supposedly in its low-power mode. To an observer, the two machines were indistinguishable from each other at this time – power LED blinking, fans off, silent operation – but the difference in power usage was outrageous.
The second lesson appears to be that Windows 7 draws less power when you’re not using it. Later on I tested both machines using a CPU stress test, and they pulled the same amount of power, but when left idle, the Windows 7 machine averaged 10W less.
I should note that it’s entirely possible the RM background tasks were responsible for the latter discrepancy; I didn’t have a non-RM XP machine to test. No such difference could explain the sleep mode difference. Similar results emerged on different hardware, so this didn’t appear to be an anomaly with the Dell machines.
So, how much is that in cold hard cash? We’ll look at some more surprising results in part 2 later this week.
The FT reported today that “Google is phasing out the internal use of Microsoft’s ubiquitous Windows operating system because of security concerns“. A lot of people are talking about the same tired and obvious aspects of this; Google pushing their own platforms, Windows being insecure, blah blah blah. I don’t care about that, especially since the benefits of Microsoft vs. Apple/Linux/whoever is one of those topics about which everyone who cares already has an opinion, and isn’t likely to change it.
What I want to point out is that this means Google products that run on the desktop will soon start to be utter garbage when run on Windows.
It is inevitable that without Windows machines in the corporate IT estate, Windows development will not matter as much to the company. When your software crashes and it affects your employees, that drives a fix harder than a thousand times as many customers with the same problem. From now on, crashes in the Windows products will not affect Google employees. And they will care less, even if most of their customers are using Windows. Don’t believe me? I thought you might not.
Just look at Apple.
iTunes is an application beholden to millions – including millions who use a PC – and yet almost everyone I’ve met who has run it on both Windows and OS X has told me that the Windows version is garbage in comparison. I know from years of experience that QuickTime is an utter nightmare on Windows, frequently breaking or delivering dire performance. The simple fact is that Apple never see those problems because, of course, no-one at Apple uses Windows internally. So, no-one at Apple cares to do anything about it.
Apple does of course have a vested interest in iTunes and QuickTime running better on OS X, but I honestly don’t beleive that iTunes is deliberately unstable and cack just to drive people to buy a Mac. It’s simply because their Windows programmers suck due to complete inexperience with the platform, and the same thing is going to happen at Google.
In the long run, it may not matter. If the entirety of Google’s product line-up completes its buzzword-filled move to the “The Cloud”, then hopefully it won’t matter that Google coders can’t produce quality code on Windows. But in the meantime, get ready for Chrome, Google Earth, Google Desktop, Sketchup, and Picasa to start sucking big time. The developers aren’t using Windows any more, and their bosses want every application in the browser.
Why should they care if your Windows program crashes?
I recently fell foul of an irritating problem on my Windows 7 workstation in my office; the Jump List for Windows Explorer had suddenly emptied itself. I had quite a few pinned locations, and for the next week or so I was frustrated several times a day when I instinctively right-clicked on the Explorer icon to open a frequently-used folder. It’s interesting how quickly you get used to a feature like that.
I tried to recreate my pinned items list by dragging folders to the Taskbar icon, but to no avail. I tried logging off and back on. I tried restarting. I tried sacrificing an iPod under a full moon. Nothing I tried would coax the Jump List back to life. Windows 7 was no longer my friend. Harsh words were uttered.