It’s been an interesting week. After months of waiting, I managed to finally get myself onto the beta of Office 365. Office 365 is Microsoft’s latest software as a service offering, which is currently in beta. It consists of Office, Lync, Exchange and SharePoint. The latter three are hosted services where you use a client to access the hosted resources; Office can be consumed either locally (with cloud based document storage), of via the Office web apps (i.e. office in the browser).
It’s taken a few days to get myself up an running, but that’s mainly lack of time! While the setup and installation was simple, I’m still getting to grips with the basics and with working around some of the initial issues. The basic opinion so far is highly positive.
For me, the office component of Office offers little advantage to me – although the cost is highly attractive. I’ve always used Office (i.e. Word, Excel, PowerPoint) locally anyway – and have enough computing power to always run local clients. But I can see how attractive this might be for many small businesses (and not a few bigger ones too).
The basic signup process was simple – a few web pages and the Office 365 account was created, and I was able to logon to the main portal, which looks like this:
From this portal page, you can do all the tenant management actions along the panel on the left, and configure the services with the middle panel. Along the centre top and right hand side is simple help and access to help resources. All in all, a simple and clean interface into Office 365. Setting up the individual services was relatively straightforward, but if you are going to get value out of SharePoint, you have to know SharePoint a whole lot better than I do at present.
The Office 365 Exchange part – well it’s just a hosted Exchange server. The speed is good – it’s really very much what I’d have expected. It does have PowerShell Cmdlets. To get to these is very simple, as follows:
# First Get credential for site
$cred = Get-Credential tfl@yourOffice365domain.onmicrosoft.com
# Next create a new PS Session
# Use a hash table to setup parameters to new-pssession
$Office365 = @{ ConfigurationName = "Microsoft.Exchange"
Connectionuri = "Https://ps.outlook.com/powershell"
Credential = $cred
Authentication = "Basic"
AllowRedirection = $true}
$s = New-PsSession @Office365
# Note: you see the session being redirected to your site
# Next Import the remote session
$Results = Import-PsSession $s
# And away you go. Here are some things to try:
# How many cmdlets returned?
$Results.ExportedFunctions.count
# What mailbox cmdlets do we have gcm *.Mailbox
# Get mail boxes and statistics
Get-Mailbox Get-Mailbox | Get-MailBoxStatistics
It’s all quite straightforward although the remoting aspect of this means it breaks PowerShell’s Get-Help at least to some degree. The remote session to the server is very much limited (don’t enter the PSSession – even exit is disallowed!). You run all the cmdlets from the local PowerShell console. I’ve not seen PowerShell cmdlets for SharePoint or Lync yet, but I expect they will work in a very similar manner. One further thing you appear NOT able to do is run New-Mailbox to create mailboxes. At least, I’ve not managed to. The documentation does not specifically mention creation of mailboxes by PowerShell, but that may be an oversight or just documentation in production. I’ve got a test script that fails – which is a by product of the restricted session configuration object being used (Microsoft.Exchange).
SharePoint is not a product I know all that well yet. I can use it in a basic way, but I’ve got no real experience either managing or designing SharePoint sites. With Office 365 you get a single ‘vanity’ domain (i.e. Internet facing), as with BPOS, which is nice. I can see small businesses wanting to use this for their ‘shop front’. Ad of course, you get lots more available ‘inside’ your organisation. I definitely need to work more with this, but it looks like a good implementation. Shame their cmdlets are not be available yet. I would hope that Microsoft would ensure these are working before sending Office 365 to the masses, but we may not be that lucky.
Lync was a doddle to install – just download and run the client, login and away you go. In my case, it was marginally more complex to logon as my domain account is a pure local account, separate from the Office 365 account. But with a tad more typing, I was logged in. Enabling Federation was simple, but turns out there are two big gotchas that I came across.
1. First, “Public Internet Connectivity”
only includes Microsoft’s Live Messenger (aka MSN messenger) – AOL and Yahoo are not enabled and so far as I can tell there is no XMPP gateway features either. So that means no XMPP federation with Google, etc. And the time it takes to get federated even to MSN is slow – It’s been two days now and I’m still waiting to be able to access Live Messenger users. Fuller PIC federation would have been nice.
2. Second, Open Federation does not work initially with existing Lync customers until they do additional work on their Edge architecture. While you can indeed open federate from your Office 365 account, and you can get it to work, if you try to federate with any partner that has on-premise Lync, it initially fails. They need to do some more configuration to enable a new hosting provider. My good pal Tom Arbuthnot pointed me to a great post from my other old buddy Russ Kaufmann that some how I’d missed. Basically, if you are running on-premise Lync, Office 365 appears as a hosting provider, and your account there does not appear to be just another open federated domain. Russ argues that this is because Microsoft “
doesn’t seem to know how to implement their own product”. He might think that, but I couldn’t possibly comment. The good news is that Russ has a fix which is to run New-CSHostingProvider to add a new service entry for Lync Online. See
http://infrastructurehelp.wordpress.com/2011/03/15/office-365a-serious-flaw-with-lync/ for the details and Russ’s views.
I would have hoped that this is just a ‘feature’ of the beta, and gets fixed for RTM. Russ is right that I, as a hosting tenant, should have my domain treated for open federation just like any other domain, and not hindered by virtue of being hosted at Microsoft. If I, as an Office 365 Lync On=Line user, want to federate with someone that has enabled open federation, I should be able to do that without more admin work on
their part.
But now that we know that, I can just get all my contacts to open up their edge servers and we can move past it. As I said, I hope MS can fix this by RTM, as I tend to agree with Russ! But then I usually agree with Russ!
The other components of Lync Online, like conferencing and peer-peer audio seem find. Once Tom and I got his Edge server sorted out, we were able to IM, he’s in my contacts list and I can see presence. We tested peer-peer IM, audio and desktop sharing. It all worked as it’s supposed to. The audio quality, once I got my mike plugged in correctly, was excellent. We did not test video only due to lack of camera at my end. I will be testing this during the week.Sadly, like SharePoint Online, I can’t find any cmdlets yet for Lync Online.
All in all, Office 365 looks like compelling. The price plans (a subject for another blog post!) look very interesting. I am almost certainly going to move a secondary domain onto it and use it to learn more about the suite. I’ll be writing more in the coming weeks, particularly with more details on the PowerShell cmdlets for Lync and SharePoint once I get hold of them.
And if you fancy trying things out, you can get me, at least for now, on Lync as:
tfl@cookham.onmicrosoft.com. Feel free to IM me and help me test this out!
