The implications of Office 365

Microsoft have released Office 2016 via the 365 ‘service-based’ offering and touted this to enterprises as the ‘quick and easy way to consume the new features’.

Having worked with the product, we were surprised to find a few things not quite obvious:

  • Its VERY different to deploying Office 2016 or select media – this is a new model/paradigm, not JUST a licensing wrapper on the product.
  • Office 365 subscription is either 2013 or 2016 (people keep talking about 365, but they rarely clarify…)
  • The other crucial item, is Office 365 is essentially a client-less App-V.
    It’s not an App-V you can mount and publish, but it sure doesn’t install into Program Files (x86)\Microsoft Office\Office16 either… – That’s Office 2016…
    As such, it isn’t quite as ‘integrate-able’ as one would expect – sure the common FTA’s, ProgIDs and other usual entry points are exposed to the client as you’d expect.  This means there’s no issue with code calling Word.Application, .doc, or the other basic examples.
    BUT: if your bespoke business application relies on other bits of ‘the common Office guts’, (but not necessarily ‘Office’ such as MSComCTL.OCX, for example), you’re in for some investigation if you weren’t aware of this dependency…

While there are multiple plans for SharePoint and Exchange add-ons, there didn’t appear to be anything less than Proplus – You don’t get to granularly control features (*during deployment*) like you could with earlier editions, assuming you wanted to apply an MSP to control feature states.  Its just waaay easier to deploy the lot – turning on Access and Publisher after the fact isn’t trivial…

Advertisements

Busting out of App-V 5 bubbles on Citrix XenApp servers

There’s a slight pre-req here, that may not be configured in production environments.

  • It does require IE being allowed to browse to local paths from the address bar – this may be locked down through Group Policy

Consider something goes wrong and, to diagnose the users scenario further, one wants to interrogate and alter the users environment without getting changes caught in the wrong bubble – there’s an ‘easy’ way to break out of the virtual environment below.

Start with launching an IE-based published shortcut (that is presumably part of a bubble).  Of course, if you’ve got a file-open dialog, it ought to work too, so any notepad-like tool ought to suffice.  Get creative, you’ll be rewarded later.

Change the address to the C:\ of the server:

busting out of bubbles(2)

Explorer.exe is now a child-process of the published app.  Navigate to System32 and double-click on CMD.EXE to run it on the server(this is a remote process):

busting out of bubbles(1)

Close the existing IE window down – This is important as we don’t want the OS re-using the process in a moments time.  So we’ve got a console, but we’re still ‘in’ the bubble.

If you traverse to Powershell.exe you can confirm as below:

busting out of bubbles(3)

Execute ‘start-process http://test‘ in PoSH (or ‘start http://test‘ in CMD) and you’ve broken ‘out’ of the bubble – this is the ‘hook’ that breaks outside App-V’s virtualisation environment.

  • Doesn’t need to be a real URL of course, we just want an IE window.
  • Using ‘about:blank’ doesn’t work either – colon’s are reserved…

Because you are launching the http:// protocolhandler, it bypasses the usual mechanisms and (somehow) steps outside of the bubble – this OS function appears to be ‘beneath’ the App-V ‘stack’.

  • If you want an IE within the bubble, properly pass the executable path ‘”C:\Program Files (x86)\Internet Explorer\iexplore.exe” {URL}’.
  • This works on App-V 5 SP1 and SP3

Now you’ve got a console, external to any virtual environment.  Close down the other processes (explorer.exe window and cmd.exe) to let the virtual environment shut down gracefully.  Citrix will keep your session open just fine.

Repeat the browse loophole to re-launch another Powershell session (this time outside the bubble) if you wish to prove the point:

busting out of bubbles(4)

Sure, it would’ve been easier to just publish CMD.EXE, but maybe that’s not a given in production. Maybe that’s not delivered to your user that’s just reported an issue, right?

It’s always useful to know how to subvert the environment for troubleshooting purposes…

Delivering old JREs or ActiveX controls in bubbles

I’d love to say this was my idea, but this was all Oren Werker – props to you for asking for what we didn’t know we needed!

What to do when you have App-V 5 (sp1) and want to deliver ActiveX controls for poorly built websites?

You sure don’t want to install them natively and have to deal with conflicting .DLLs! (Its not like we had a view of all that the business was using, so we containerised by default)

We found that one doesn’t have to use a common published ‘extension point’ to instantiate an appv. Additionally, one doesn’t have to publish a shortcut that refers to one if the main ApplicationIDs in the appv XML…

Any  EXE in the integration root or package root is launched ‘in the bubbles context’ (the caveat here is, of course, unless it’s from another appv – no spelunkers allowed!)

So what’s to do? Build an .EXE that takes arguments and promptly runs them of course!

I bodged an AHK that does just that, RunIE.EXE would take any URL and throw it at IE9 (the natively installed browser). If we chuck this .EXE in an appv with any old JRE or crystal reports .DLLs, it’ll load and render approximately. This kept the process in its own sandbox and allowed users to run many conflicting JRE’s as required.

No app silo based on the 1.6 JRE any more!

This eventually grew, we wanted a RunEXE.EXE as well (great for access databases needing horrible old runtimes).

These tools soon merged together and a bitmask argument was added for window handling (hidden, minimised etc) or IE in ‘app mode’ (with no address or toolbars).

Turned out to be a great tool, crucial to the delivery of many horrible old systems and applications the businesses were stuck on.

I’ll post the code, but with some experimentation in AHK or AU3, one should be able to emulate this…

We would often hold launch scripts on remote drives that the .EXE would call. PowerShell swapping .INI files onto the PVAD and all sorts.

Get creative, what could go wrong? (We were already in a hospital…)