Unable to send mail in Outlook Web App using Google Chrome

Posted on By Mark Wilson
This content is 13 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

For the last few days, I’ve been getting frustrated with my Office 365 Outlook Web App in Google Chrome. Microsoft has worked to ensure that the latest web apps work well in other popular  browsers but each time I replied to an email, the message would not send. The URL was displayed in the bottom of the window (as though a call to the server was being made) but then nothing – no saving to my Drafts folder either, just the ability to close the window and lose the work.

I googled the problem and found a thread that gave me the answer:  it seems there is a conflict with the Click to call with Skype extension (I was using v5.6.0.8153 in Chrome v13.0.782.22). As soon as I disabled the extension (no need to uninstall), I was able to send mail from the Outlook Web App again.

“5 reasons to avoid Office 365?” Are you really sure about that?

Posted on By Mark Wilson
This content is 14 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

It’s not often these days that I feel the need to defend Microsoft. After all, they’re big boys and girls who can fight their own battles. And yes, I’m an MVP but if you ask Microsoft’s UK evangelists (past and present), I’m sure they’ll tell you I’m pretty critical of Microsoft at times too…

So I was amazed yesterday to read some of the negative press about Office 365. Sure, some Microsoft-bashing is to be expected. So is some comparison with Google Apps. But when I read Richi Jennings‘ 5 reasons to avoid Microsoft Office 365 , I was less than complementary in my reaction.  I did leave a lengthy comment on the blog post, but ComputerWorld thinks I’m a spammer… and it was more than 140 characters so Richi’s Twitter invitation for constructive comments for his next post (5 reasons to embrace Office 365) was not really going to work either.

Picking up Richi’s arguments against Office 365:

  • On mobility. I’ll admit, there are some issues. Microsoft doesn’t seem to understand touch user interfaces for tablets (at least not until they have their own, next year perhaps?) so the web apps are not ideal on many devices. Even so, I’m using Exchange Online with my iOS devices and the ActiveSync support means it’s a breeze. We don’t have blanket WiFi/3G coverage yet (at least not here in the UK) so it is important to think about offline working and I’m not sure Microsoft has that sorted, but neither does anyone else that I’ve found. Ideally, Microsoft would create some iOS Office apps (OneNote for iPhone is not enough – it’s not a universal app and so is next to useless on an iPad) together with an Android solution too…
  • I don’t see what the issue is with MacOS support (except that the option to purchase a subscription to Office Professional Plus is Windows-only). I’m using Office 365 with Office for Mac and SharePoint integration is not as good as on Windows but there seems nothing wrong with document format fidelity or Outlook connecting to Exchange Online. I’ve used some of the web apps on my Mac too, including Lync.
  • Is £4 a month expensive for a reliable mail and collaboration service? I’m not sure that the P1 option for professionals and small businesses (which that price relates to) is “horribly crippled” either. If the “crippling” is about a lack of support, I left Google Apps because of… a lack of support (after they “upgraded” my Google Apps account but wanted me to change the email address on my then-orphaned “personal” account – and you think Microsoft makes it complex?)
  • Forest Federation is a solution that provides clear separation between cloud and on-premise resources. It may be complicated, but so are enterprise requirements for cloud services.  If that’s too complex, then you don’t probably don’t need Active Directory integration: try a lower-level Office 365 subscription…
  • As for  reliability, yes, there have been BPOS Outages. Ditto for Azure. But didn’t Google have some high-profile GMail outages recently? And Amazon? Office 365 (which was a beta until yesterday) has been pretty solid.  Let’s hope that the new infrastructure is an improvement on BPOS, but don’t write it off yet – it’s only just launched! Microsoft is advertising a financially-backed 99.9% uptime agreement…

The point of Office 365 is not to move 100% to the cloud but to “bring office to the cloud” and use it in conjunction with existing IT investments (i.e. local PCs/Macs and Office).  If I’m a small business with few IT resources, it lets me concentrate on my business, rather than running mail servers, etc. Actually, that’s the sweet spot. Some enterprises may also move to Office 365 (at least in part) but, for many, they will continue to run their mail and collaboration infrastructure in house.

Richi says that, if he were a Microsoft Shareholder, he’d be “bitterly disappointed with [yesterday’s] news”. The market seems to think otherwise… whilst Microsoft stock is generally not performing well, it’s at least rising in the last couple of days…

Microsoft stock price compared with leading IS indices over the last 12 months

To be fair, Richi wasn’t alone, but he was the one with the headline grabbing post… (would it be rude to call it linkbait?)

Over on Cloud Pro, Dennis Howlett wasn’t too impressed either. He quoted Mary Jo Foley’s Office 365 summary post:

“Office 365 is not Office in the cloud, even though it does include Office Web Apps, the Webified versions of Word, Excel, PowerPoint and OneNote. Office 365 is a Microsoft-hosted suite of Exchange Online, SharePoint Online and Lync Online €” plus an optional subscription-based version of Office 2010 Professional Plus that runs locally on PCs. The Microsoft-hosted versions of these cloud apps offer subsets of their on-premises server counterparts (Exchange, SharePoint and Lync servers), in terms of features and functionality.”

Yep, that’s pretty much it. Office 365 is not about competing with Office, it’s about extending Office so that:

  • It’s attractive to small and medium-sized businesses, so that they don’t need to run their own server infrastructure.
  • There are better opportunities for collaboration, using “the cloud” as a transport (and, it has to be said, giving people less reason to move to Google Apps).

Dennis says:

“Microsoft has fallen into the trap that I see increasingly among enterprise vendors attempting to migrate their business models into the cloud: they end up with a half baked solution that does little for the user but gives some bragging rights. All the time, they seek to hang on grimly to the old business model, tinkering with it but not taking the radical steps necessary to understand working in the cloud.”

Hmm… many enterprises are not ready to put the data that is most intimately linked to their internal workings into the cloud. They look at some targeted SaaS opportunities; they might use IaaS and PaaS technologies to provide some flexibility and elasticity; they may implement cloud technologies as a “private cloud”. But Office 365 allows organisations to pick and choose the level of cloud integration that they are comfortable with – it might be all (for example, my wife’s small business) or none (for example me, working for a large enterprise), or somewhere in between.

Office 365 has some issues – I’m hoping we’ll see some more development around mobility and web app functionality – but it’s a huge step forward. After years of being told that Windows and Office are dead and that Microsoft has no future, they’ve launched something that positions the company for both software subscriptions (which they’ve been trying to do for years) and has the ability to host data on premise, in the cloud, or in a hybrid solution. “The cloud” is not for everyone, but there aren’t many organisations that can’t get something out of Office 365.

Domain management for Office 365 (Small Business)

Posted on By Mark Wilson
This content is 14 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

A few weeks ago, I wrote about configuring DNS for Exchange Online in Office 365. In that post, I mentioned that Microsoft is only supporting small business customers with domains that are delegated to (i.e. hosted on) Microsoft’s name servers – currently ns1.bdm.microsoftonline.com and ns2.bdm.microsoftonline.com.

I wasn’t entirely comfortable with this (for a start, the Office 365 DNS Manager is best described as “basic”), so I decided to see what happens if I went through the process, but never actually switched over the name server records… as it happens it seems to work quite well (albeit in an unsupported manner).

If you want to retain control of settings, all that’s involved is creating the same records with an external DNS provider.

For reference, on the markwilson.co.uk domain, these would be:

markwilson.co.uk. 3600 IN MX 0 markwilson-co-uk.mail.eo.outlook.com.
autodiscover 3600 IN CNAME autodiscover.outlook.com.
markwilson.co.uk. 3600 IN TXT “v=spf1 include:outlook.com ~all”
SRV _sip _tls 443 1 100 sipdir.online.lync.com. markwilson.co.uk 3600
SRV _sipfederationtls _tcp 5061 1 100 sipfed.online.lync.com. markwilson.co.uk 3600

Of course, if Microsoft changes the server names, you won’t be notified and that might affect your service but the settings seem to be the same as the ones provided to Enterprise customers as part of their domain management process.

Then, go through the normal process to add a domain to Office 365, but just click Next on the Edit Name Server Records page:

Ignore the step that advises changing DNS entries

At the time of writing, Office 365 is still in beta, so things could change (for example, the domain verification process has already switched from using CNAME records to using either TXT or MX records) but it might be worth a try…

[Update 20 June 2011: Microsoft has documented a workaround for domains that do not allow delegation (specifically for .NO and .DK but I see no reason why other domains should not be used in this way)]

Office 365 message filtering (and a horrible little bug that leaves email addresses exposed…)

Posted on By Mark Wilson
This content is 14 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

One of my concerns with my recent switch from Google Apps Mail to Microsoft Office 365 was about spam email. You see, I get none.  Well, when I say I get none, I get plenty but it’s all trapped for me. With no effort on my part. Only a handful of missed spam messages in the last 2 or 3 years and almost as few false positives too.

I’ve had the same email address for about 12 years now (I think), and it’s been used all over the web. Some of my friends are more particular though – and, perhaps understandably, were annoyed when I accidentally emailed around 40 people with e-mail addresses visible in the To: field today. Except that I hadn’t intended to.

I think I’ve found a bug in Office 365’s Outlook Web App (at least, I hope it’s not closed as “by design”, assuming I find out how to file a bug report). If I send to a distribution group, it automatically expands the addresses and displays them to all recipients. That’s bad.

The annoying thing is that, previously, I had been BCCing the recipients. I have a feeling that at least one organisation was rejecting my mail because there was nothing in the To: field (although it didn’t like Google’s propensity to send mail from one domain “on behalf of” another address either), so I thought I’d use a list instead and the recipients would see the list name, rather than the actual email addresses. Thankfully it was only sent to my closest freinds and family (although that’s not really the point).

So, back to spam and Office 365 – does it live up to my previous experience with Google Apps Mail? Actually, yes I think it does. I’ve had to teach it a couple of safe senders and block a couple of others, but it really was just a handful and it’s settled down nicely.

All of Microsoft’s cloud-based e-mail services use Forefront Online Protection for Exchange. Enterprise administrators have some additional functionality (adapting SCL thresholds, etc.) but things seem to be working pretty well on my small business account too. Digging around in the various servers that the mail passes through sees hosts at bigfish.com and frontbridge.com – Frontbridge was an aquisition that has become part of Exchange Hosted Services (and it started out as Bigfish Communications) – so the technology is established, and another Microsoft property (Hotmail) is a pretty good test bed to find and filter the world’s spam.

Migrating mail and contacts from Google Mail to Office 365

Posted on By Mark Wilson
This content is 14 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

I started to write this post in September 2008, when it was titled “Importing legacy e-mail to my Google Apps account”. A few years on and I’m in the process of dumping Google Apps in favour of Microsoft Office 365 (if only Microsoft had a suitable offering back then, I might not have had to go through this) but I never did manage to bring all my mail across from my old Exchange server onto Google.

The draft blog post that I was writing back then (which was never published) said:

First of all, I backed up my Exchange mailbox. I also backed up my Google Mail and, whilst there are various methods of doing this, I used Outlook again, this time to connect to my Google Apps account via IMAP and take a copy into a PST file. With everything safe in a format I knew how to access if necessary, I set about the import, using the Google Email Uploader to import my Outlook mailbox into my Google Apps account.

Rather than import into my live mailbox straightaway, I brought the legacy messages into a new mailbox to test the process. Then I did the same again into my real e-mail

With many years worth of e-mail to import (29097 messages), this took a long while to run (about 20 hours) but gradually I saw all the old messages appear in Google Mail, with labels used to represent the original folder names. There were a few false starts but, thankfully the Google Email Uploader picks up where it left off. It also encountered a few errors along the way but these were all messages with suspect attachments or with malformed e-mail addresses and could be safely disregarded (I still have the .PST as a backup anyway) .

Except that I never did get my mailbox to a state where I was happy it was completely migrated. Uploading mail to GMail was just too flaky; too many timeouts; not enough confidence in the integrity of my data.

In the end, I committed email suicide and started again in Google Apps Mail. I could do the same now in Office 365 but this time I don’t have an archive of the messages in a nice handy format (.PST files do have their advantages!) and anyway, I wanted to be able to bring all of my mail and contacts across into my nice new 25GB mailbox (I’ve written previously about synchronising my various calendars – although I should probably revisit that too some time)

Migrating contacts

Migrating my contacts was pretty straightforward. I’m using a small business subscription on Office 365 so I don’t have the option of Active Directory integration – the enterprise plans have this but I exported my contacts from GMail in .CSV format and brought them back into Office 365 through the Outlook web app.

One thing that’s worth noting – Google Mail has an option to merge duplicate contacts – I used this before I exported, just to keep things clean (e.g. I had some contacts with just a phone number and others with an e-mail address – now they are combined).

Migrating mail

Microsoft seems to have thought the mail migration process for Office 365 though pretty thoroughly. I don’t have space to go into the full details here, but it supports migrations from Exchange 2007 and later (using autodiscover), Exchange 2003 (manually specified settings) and IMAP servers. After a migration batch is initiated, Office 365 attempts to take a copy of the mailbox and then synchronise any changes every 24 hours until the administrator marks the migration as complete (during the migration period they should also switch over the DNS MX records for the DNS domain).

For GMail, IMAP migration is the option that’s required, together with the following settings:

Setting Value
IMAP Server imap.gmail.com
Authentication Basic
Encryption SSL
Port 993

(I only had one mailbox to migrate.)

Because GMail uses labels instead of Folders, I excluded a number of “folders” in the migration too to avoid duplicates. Unfortunately, this didn’t seem to take any effect (I guess I can always delete the offending folders from the imported data, which is all in a subfolder of [Google Mail]).

Finally, I provided a CSV file with the email address, username and password for each mailbox that I wanted to migrate.

Unfortunately, I’ve had a few migration failures – and the reports seem to suggest connectivity issues with Google (the Migration Error report includes messages like “Data migration for this mailbox failed because of delays on the remote server.” and “E-Mail Migration failed for this user because no e-mail could be downloaded for 1 hours, 20 minutes.“. Thankfully, I was able to restart the migration each time.

Monitoring the migration

Monitoring the migration is pretty straightforward as the Exchange Online portion of Office 365 gives details of current migrations. It’s also possible to control the migration from the command line. I didn’t attempt this, but I did use two commands to test connectivity and to monitor progress:

Test-MigrationServerAvailability -imap -remoteserver imap.gmail.com -port 993

and:

Get-MigrationStatus

Details of how to connect to Office365 using PowerShell can be found in my post about changing the primary email address for Office 365 users.

Points of note

I found that, whilst a migration batch was in process, I needed to wait for that batch to finish before I could load another batch of mailboxes. Also, once a particular type of migration (Exchange 2003, 2007 or IMAP) has been started, it’s not possible to creat batches of another type until the migration has been completed. Finally, completing a migration can take some time (including clean up) before it’s possible to start a new migration.

Wrap-up

It’s worth noting that Office 365 is still in beta and that any of this information could change. 24 hours seems a long while to wait between mailbox synchronisations (it would be good if this was customisable) but the most significant concern for me is the timeouts on mailbox migrations. I can rule out any local connectivity issues as I’m migrating between two cloud services (Google Apps Mail and Office 365) – but I had enough issues on my (single mailbox) migration to concern me – I wouldn’t want to be migrating hundreds of mailboxes this way. Perhaps we’ll see third party tools (e.g. from Quest Software) to assist in the migration, comparing mailboxes to see that all data has indeed been transferred.

Changing the primary email address for Office 365 users

Posted on By Mark Wilson
This content is 14 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

In my recent post about configuring DNS for Office 365, I mentioned that Microsoft creates mailboxes in the form of user@subdomain.onmicrosoft.com.  I outlined the steps for adding so-called “vanity” domains, after which additional (proxy) email addresses can be specified but any outbound messages will still be sent from the onmicrosoft.com address (at least, that’s what’s used in the beta – I guess that may change later in the product’s lifecycle).

It is possible to change the primary address for a user (e.g. I send mail using an address on the markwilson.co.uk domain) but it does require the use of PowerShell.  Time to roll up your sleeves and prepare to go geek!

Connecting to Office 365 from Windows PowerShell

I was using a Windows 7 PC so I didn’t need to update any components (nor do Windows Server 2008 R2 users); however Windows XP SP3, Server 2003 SP2, Server 2008 SP1 or SP2 and Vista SP1 users will need to make sure they have the appropriate versions of Windows Powershell and Windows Remote Management installed.

Once PowerShell v2 and WinRM 2.0 are installed, the steps to connect to Office 365 were as follows:

Prompt for logon credentials and supply the appropriate username and password:

$LiveCred = Get-Credential

Create a new session:

$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell/ -Credential $LiveCred -Authentication Basic -AllowRedirection

Import the session to the current PowerShell console:

Import-PSSession $Session

At this point, the session import failed for me because script execution was disabled on my machine. That was corrected using Set-ExecutionPolicy -ExecutionPolicy unrestricted (although that’s not a great idea – it would be better to use a lower level of access) – I also had to run PowerShell as an administrator to successfully apply that command.

Once scripts were enabled, I was able to import the session.

List the current mailbox addresses

It’s possible that a mailbox may have a number of proxy addresses already assigned, so this is the code that I used to list them:

$Mailbox = Get-Mailbox -Identity Mark-Wilson
$Mailbox.EmailAddresses

If you want to format the list of mailboxes as a single comma-separated line, then this might help:

ForEach ($i in $Mailbox.EmailAddresses) {Write-Host $i -NoNewline “`b, “}

(the `b is a backspace escape character.)

Set the primary email address

The primary email address is shown using an upper case SMTP: prefix whereas proxy addresses use a lower case smtp: prefix.

To change the primary email address, it’s necessary to reset all addresses on the mailbox with the Set-Mailbox cmdlet.  This is where some copying/pasting of the output from the previous command may help:

Set-Mailbox Mark-Wilson -EmailAddresses SMTP:mark@markwilson.co.uk,smtp:mark-wilson@markwilson.onmicrosoft.com,smtp:mark@markwilson.it

Disconnect the session from Office365

Once all changes have been made, it’s good practice to break down the session again:

Remove-PSSession $Session

Configuring DNS for Exchange Online in Office 365

Posted on By Mark Wilson
This content is 14 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

Readers who follow me on Twitter (@markwilsonit) may have noticed that I was in a mild state of panic last night when I managed to destroy the DNS for markwilson.co.uk.  They might also have seen this website disappear for a few hours until I managed to get things up and running again. So, what was I doing?

I’ve been using Google Apps for a couple of years now but I’ve never really liked it – Docs lacks functionality that I have become used to in Microsoft Office and Mail, though powerful, has a pretty poor user interface (a subjective view of course – I know some people love it).  When Microsoft announced Office 365 I was keen to get on the beta, and I was fortunate enough to be accepted early in the programme.  Unfortunately, at that time, the small business (P1) plan didn’t allow the use of “vanity domains” (what exactly is vain about having your own domain name? I call it professionalism!) so I waited until I was accepted onto the enterprise (E3) beta. Then I realised that moving my mail to another platform was not a trivial exercise and, by the time I got around to it several weeks had gone by and it is now possible to have vanity domains on a small business plan!

Anyway, I digress: migrating to Office 365, how was it? Well, first up, I should highlight that the DNS issues I had were nothing to do with Microsoft – and, without those issues, everything would have been pretty simple actually.

Microsoft provides a portal to administer Office 365 accounts and this also allows access to the Exchange Online, Lync Online and SharePoint Online components.  In that regard, it’s not dissimilar to Google Apps – just a lot more pleasant to use. So far, I’ve concentrated on the Exchange Online and Outlook Web App components – I’ll probably blog about some of the other Office 365 components as I start to use them.

The e-mail address that Microsoft gave me for my initial mailbox is in the form of user@subdomain.onmicrosoft.com. That’s not much use to me, so I needed to add a domain to the account which involves adding the domain, verifying it (by placing a CNAME record in the DNS for the appropriate domain – using a code provided by Microsoft, resolving to ps.microsoftonline.com.) and then, once verified, configuring the appropriate DNS records. In my case that’s:

markwilson.co.uk. 3600 IN MX 0 markwilson-co-uk.mail.eo.outlook.com.
autodiscover 3600 IN CNAME autodiscover.outlook.com.
markwilson.co.uk. 3600 IN TXT “v=spf1 include:outlook.com ~all”

These are for Exchange – there are some additional records for Lync but they show how external domain names are represented inside Office 365.

[Update 17 June 2011: The DNS entries for Lync are shown below]

SRV _sip _tls 443 1 100 sipdir.online.lync.com. markwilson.co.uk 3600
SRV _sipfederationtls _tcp 5061 1 100 sipfed.online.lync.com. markwilson.co.uk 3600

The . on the end of the names and the quotes on the TXT record are important – without the . the name resolution will not work correctly and I think it was a lack of " " that messed up my DNS when I added the record using the cPanel WebHost Manager (WHM), although I haven’t confirmed that.

With the domain configured, additional email addresses may be added to user accounts and, once DNS propagation has taken place, mail should start to flow.

Before I sign off, there are a few pieces of advice to highlight:

  • After I got everything working on the Office 365 Enterprise (E3) plan, I realised that I’d be better off using the Small Business (P1) plan. This wasn’t a simple subscription choice (I hope it will be in the final product – at the time of writing Office 365 is still in beta) and it involved me removing my “vanity” domains from all user objects, distribution groups, contacts and aliases, then removing the domain from Office 365, and finally going through the process of adding it using a different Microsoft Online account.
  • Before making DNS changes, it’s worthwhile tuning DNS settings to reduce the time to live (TTL) to speed up the DNS propagation process by reducing the time that records are stored in others’ DNS caches.
  • Microsoft TechNet has some useful advice for checking DNS MX record configurations with nslookup.exe but Simon Bisson pointed me in the direction of the Microsoft Exchange Remote Connectivity Analyzer, which is a great resource for checking Exchange ActiveSync, Exchange Web Services and Office Outlook connectivity as well as inbound and outbound SMTP email.
  • Microsoft seems to have decided that, whilst enterprises can host their DNS externally, small businesses need to host their DNS on Microsoft’s name servers (and use a rather basic web interface to manage it).  I’m hoping that decision will change (and I’m led to believe that it’s still possible to host the DNS elsewhere, as long as the appropriate entries are added, although that is an unsupported scenario) – I’m trying that approach with another domain that I own and I may return to the topic in a future blog post.

Now I have my new mailbox up and running, I just need to work out how to shift 3GB of email from Google Apps to Exchange Online!

Azure Connect – the missing link between on-premise and cloud

Posted on By Mark Wilson
This content is 14 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

Azure Connect offers a way to connect on-premise infrastructure with Windows Azure but it’s lacking functionality that may hinder adoption.

While Microsoft is one of the most dominant players in client-server computing, until recently, its position in the cloud seemed uncertain.  More recently, we’ve seen Microsoft lay out its stall with both Software as a Service (SaaS) products including Office 365 and Platform as a Service (PaaS) offerings such as Windows Azure joining their traditional portfolio of on-premise products for consumers, small businesses and enterprise customers alike.

Whereas Amazon’s Elastic Compute Cloud (EC2) and Simple Storage Service (S3) offer virtualised Infrastructure as a Service (IaaS) and Salesforce.com is about consumption of Software as a Service (SaaS), Windows Azure fits somewhere in between. Azure offers compute and storage services, so that an organisation can take an existing application, wrap a service model around it and specify how many instances to run, how to persist data, etc.

Microsoft also provides middleware to support claims based authentication and an application fabric that allows simplified connectivity between web services endpoints, negotiating firewalls using outbound connections and standard Internet protocols. In addition, there is a relational database component (SQL Azure), which exposes relational database services for cloud consumption, in addition to the standard Azure table storage.

It all sounds great – but so far everything I’ve discussed runs on a public cloud service and not all applications can be moved in their entirety to the cloud.

Sometimes makes it makes sense to move compute operations to the cloud and keep the data on-premise (more on that in a moment). Sometimes, it’s appropriate to build a data hub with multiple business partners connecting to a data source in cloud but with applications components in a variety of locations.

For European CIOs, information security, in particular data residency, is a real issue. I should highlight that I’m not a legal expert, but CIO Magazine recently reported how the Patriot Act potentially gives the United States authorities access to data hosted with US-based service providers – and selecting a European data centre won’t help.  That might make CIOs nervous about placing certain types of data in the cloud although they might consider a hybrid cloud solution.

Azure already provides federated security, application layer connectivity (via AppFabric) and some options for SQL Azure data synchronisation (currently limited to synchronisation between Microsoft data centres, expanding later this year to include synchronisation with on-premise SQL Server) but the missing component has been the ability to connect Windows Azure with on-premise infrastructure and applications. Windows Azure Connect provides this missing piece of the jigsaw.

Azure Connect is a new component for Windows Azure that provides secure network communications between compute instances in Azure and servers on premise (ie behind the corporate firewall). Using standard IP protocols (both TCP and UDP) it’s possible to take a web front end to the cloud and leave the SQL Server data on site, communicating over a virtual private network, secured with IPSec. In another scenario, a compute instance can be joined to an on-premise Active Directory  domain so a cloud-based application can take advantage of single sign-on functionality. IT departments can also use Azure Connect for remote administration and troubleshooting of cloud-based computing instances.

Currently in pre-release form, Microsoft is planning to make Azure Connect available during the first half of 2011. Whilst setup is relatively simple and requires no coding, Azure Connect is reliant on an agent running on the connected infrastructure (ie on each server that connects to Azure resources) in order to establish IPSec connectivity (a future version of Azure Connect will be able to take advantage of other VPN solutions). Once the agent is installed, the server automatically registers itself with the Azure Connect relay in the cloud and network policies are defined to manage connectivity. All that an administrator has to do is to enable Windows Azure roles for external connectivity via the service model; enable local computers to initiate an IPSec connection by installing the Azure Connect agent; define network policies and, in some circumstances, define appropriate outbound firewall rules on servers.

The emphasis on simplicity is definitely an advantage as many Azure operations seem to require developer knowledge and this is definitely targeted at Windows Administrators. Along with automatic IPSec provisioning (so no need for certificate servers) Azure Connect makes use of DNS so that there is no requirement to change application code (the same server names can be used when roles move between the on premise infrastructure and Azure).

For some organisations though, the presence of the Azure Connect agent may be seen as a security issue – after all, how many database servers are even Internet-connected? That’s not insurmountable but it’s not the only issue with Azure Connect.

For example, connected servers need to run Windows Vista, 7, Server 2008, or Server 2008 R2 [a previous version of this story erroneously suggested that only Windows Server 2008 R2 was supported] and many organisations will be running their applications on older operating system releases. This means that there may be server upgrade costs to consider when integrating with the cloud – and it certainly rules out any heterogeneous environments.

There’s an issue with storage. Windows Azure’s basic compute and storage services can make use of table-based storage. Whilst SQL Azure is available for applications that require a relational database, not all applications have this requirement – and SQL Azure presents additional licensing costs as well as imposing additional architectural complexity.  A significant number of cloud-based applications make use of table storage or combination of table storage and SQL Server – for them, the creation of a hybrid model for customers that rely on on-premise data storage may not be possible.

For many enterprises, Azure Connect will be a useful tool in moving applications (or parts of applications) to the cloud. If Microsoft can overcome the product’s limitations, it could represent a huge step forward for Microsoft’s cloud services in that it provides a real option for development of hybrid cloud solutions on the Microsoft stack, but there still some way to go.

[This post was originally written as an article for Cloud Pro.]

Quick tip for opening Microsoft Office files without installing Office

Posted on By Mark Wilson
This content is 16 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

From time to time, I find myself working on a server and thinking it would be useful to be able to open a document and, whilst WordPad usually manages to open enough of a Word document for me to get by, sometimes I need to open a spreadsheet – and this is what happened a few minutes ago when I was checking to see if a couple of hotfixes were included in Windows Server 2008 service pack 2.

Microsoft publishes this information as an Excel spreadsheet, which is all very well if I want to open it on my PC, but doesn’t help if I’m working directly on a server (which is unlikely to have any Office applications installed).

This is where my Office Live Workspace came in handy. I uploaded the file to my online Documents workspace and, within a few seconds, I was able to preview it (including searching for the relevant hotfix numbers), without having to go and find a computer with Excel installed.

Microsoft Office Live Workspace opening an Excel spreadsheet

New e-mail message continuity services

Posted on By Mark Wilson
This content is 20 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

I’ve just read about a new message continuity service from FrontBridge, designed to provide always on e-mail in today’s environment where e-mail outage is seen as a major business continuity issue.

Complementing the other e-mail managed services offered by FrontBridge, Active Message Continuity provides:

  • Always on e-mail continuity and disaster recovery with no need to “flip a switch”.
  • Interception-based archiving to capture messages “in stream” after filtering for spam, viruses and other unwanted content.
  • Continuous access via a web interface.
  • A fully managed service, starting from $1/month/user.

FrontBridge is already well established in the e-mail application service provider (ASP) market, but this new product is a key differentiator allowing FrontBridge to offer message compliance, message security and message continuity at a time when competitors such as MessageLabs are concentrating on just one area – that of message security (anti-virus, anti-spam and content control).