Office 365 Integration and Server 2012 R2 Essentials Gotcha

For our small non-profit clients, we love Windows 2012 R2’s Server Essentials role.  (We use the full standard edition because TechSoup keeps it affordable and we add the Essentials role.)

The ability to manage the Office365 tenant from inside the Essentials Dashboard really makes life easy.  We don’t have to leave the dashboard to assign licenses like we do when we’re just using other Azure sync solutions, so we like it.

But every so often, the dashboard glitches out.  Usually when this happens, it’s because the password of the admin account we use has expired, so we reset the password; relogin to the dashboard, restart the dashboard and all is well.

But today the password wasn’t expired, the dashboard just wouldn’t connect.

I spent hours poring thru logs, uninstalling the Office365 integration, then finding myself unable to reinstall it.. Happily, the client office was closed today, so I was able to restore a version of the server from 4 hours earlier (Veeam really does make it simple) until finally after I had Office365 support on the phone, and Mark, my tech, was saying “We don’t really use this anymore; everything’s ADConnect nowadays…” I stumble upon a log entry which complains:

Microsoft.WindowsServerSolutions.O365Integration.O365ConfigureException: Call Bec web service <GetCompanyInfo>b__2e() but cannot found endpoint

Horrible verb tenses aside, we had an error message… and searching “call bec web service” brought me to the Technet forum article that saved my bacon.

It turns out a URL endpoint might be cached in the registry, and if it expires and 404s and then it all goes to hell because it “cannot found endpoint.”  Delete the Endpoint URL in the registry, the Dashboard goes out to find the current one and all is well.

So I deleted the BecEndpointAddress key under:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Server\Productivity\O365Integration\Settings

and the dashboard came right back to life.

It was a good Friday after all.

Passing Command Line Arguments to a VB6 program on Windows 7/8

faxviewer_sq_header

My long national nightmare is over!

Back in the late 90s, I wrote a fax viewer program for my then employer, now client.  It was written in VB6 and has been running  without incident on their fleet of XP machines for well over a decade.

We started to migrate off XP and the fax viewer worked fine, but our ability to “launch by association” went away.  We could open the fax viewer, navigate to our folder full of faxes, open one up and do our thing; but double-clicking on a fax no longer opened the fax up automatically.

The command line was being passed just fine, but for whatever reason, the app just wouldn’t open the file.

MsgBox’s showed me the command line and it was exactly what we were passing… and so I left it as an “inconvenience” – we could still get to the fax, but not as slickly as just clicking on the link in the email.

I looked everywhere – thinking it had to do with security contexts, that the UAC was getting in the way of blahdy-blahdy-blah, I had no idea what.  I didn’t stay up on the intricacies of how the security models changed between “Run it All, All the Time” under XP to the more restrictive security models of Vista/7/8, so I figured it had to be that, and I chalked it off.

Fast forward a bit over a year, and we’re rolling out Windows 8.1 now to the rest of the desks that hadn’t gotten Windows 7.  The fax viewer works the same way on Windows 8.1 and it still drives me nuts, so I dug back  into the code to look again, put back my MsgBox’s to look at the command line arguments at runtime, and it hit me.

QUOTATION MARKS!

WindowsXP passes the command line as C:\TEMP\MYFILE.FAX and Win7/8 passes it surrounded by quotes “C:\TEMP\MYFILE.FAX” and when I did my FileExists checking using the FileSystemObject, the check failed when it was passed the filename wrapped in quotes, so it never loaded the file.

Once I stripped out the quotes from the command-line argument, then it passed the FileExists check, loaded up the document and all was well.

Only took me 13 months, but, dammit, I figured it out!

Recovering from a BSOD when restoring XP into Hyper-V

intelideWe had a mission critical XP machine go belly up — the machine interfaced with some medical hardware and couldn’t be upgraded without great expense — and the hard drive was SATA and the hardware we had to replace onto was IDE.   I made an image of the SATA drive, then restored it onto the IDE drive, and the hardware wouldn’t boot.  It just sat on a black screen with a blinking cursor.  It didn’t even have the decency to turn blue.  UBCD showed me the drive contents, so I knew everything was OK on that end, it just wasn’t booting…

So I figured I’d restore it into a Hyper-V and have a go from there.  That way the client could RDP to the VM and redirect the USB ports to the XP machine and process the data from the sensors.

Of course, upon restoration, it was Blue Screen Of Death city dead ahead, and the machine kept rebooting with the usual Inaccessible Boot Device 0x0000007B error.

VMWare has their migration assistant that after you convert your image, it will inject all of its drivers into the image to make sure everything boots.  Microsoft doesn’t seem to have such a tool, so it’s usually a bunch of frustration.

But, Technet’s Code Break blog to the rescue – P2V Migration Issues with Hyper-V: STOP: 0x0000007B — HEY!  That sounds like my issue!

And, lo and behold, the article details a bunch of registry entries that need to be present in the VMDK file in order to get the image to boot.  I mounted the VMDK, loaded the registry hive and, sure enough, there was a discrepancy — my IntelIDE key was not set to auto-start.  (And why would it, since the drive was SATA based?)

So, I changed the Start DWORD to a 0 as I was instructed in the post, and my VM started without issue!

How Am I Supposed to Uninstall a Program in Safe Mode if the Windows Installer Service Isn’t Running?!?

IMG_20140612_092942149_HDRSo, a client’s server is giving me agita — bluescreening without useful error codes and all that — and I need to uninstall some programs.

We boot into safe mode and we get some things (based on the Nullsoft installer) uninstalled, but when it comes to uninstalling things that rely on the Windows Installer service, we’re told we’re out of luck since the Installer Service can’t run in safe mode.

Useless!

Happily, there is a quick way around that, depending on which version of safe mode you’re in — “normal” or “with networking”

Open a Command Prompt with Administrative Credentials, and if you’re in the basic safe mode, run the following command:

REG ADD “HKLM\SYSTEM\CurrentControlSet\Control\SafeBoot\Minimal\MSIServer” /VE /T REG_SZ /F /D “Service”

If you’re in “with networking” you’ll need to run this command instead:

REG ADD “HKLM\SYSTEM\CurrentControlSet\Control\SafeBoot\Network\MSIServer” /VE /T REG_SZ /F /D “Service”

then, a quick

net start msiserver

and you can install and uninstall in safe mode.

Huzzah!

(Oh, and turning off verifer.exe seems to have calmed the blue-screens down.)

Hiding the Metro Tiles in Windows Server 2012 R2

Win12R2_DesktopRegA giant THANK YOU to Pierre Roman over at CanITPro (they beat us in hockey, and they’re beating the Metro interface back with a stick!) for his article: “Step-By-Step: Booting directly to the Desktop in Windows 8.1

Because of it, there is a VERY GOOD chance that I won’t be inundated with support calls Monday morning as this new terminal goes live from people who don’t know what the Metro interface is or how to use it.

But with Windows 8.1 and Server 2012 R2, Microsoft listened and gave us a way to boot directly to the desktop view of Win 8.1, and not the Start screen.

On Win 8.1 it’s an item in the Taskbar and Navigation properties dialog; but to push it out to everyone, you need to use Group Policy to push a Registry change.  This hasn’t made it to an ADMX yet.

According to the article, you want to make a new Group Policy Registry preference and push it out:

Key: HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\StartPage\
Value: OpenAtLogon
Value Type: Reg_DWORD
Value Data: “0” Boots to the Desktop
Value Data: “1” Boots to the Start Screen

And the next time they log in, they’ll go to the desktop, not Start.

Yay!