When using Ubuntu in an SMB/SME (small/medium business / small/medium enterprise) environment, the experience is typically quite painful due to issues fitting in with the overwhelming majority of Windows XP/Vista/7 installed desktop base. This spec aims to propose bringing Ubuntu closer to being able to smoothly fit into a Windows environment, with total transparency of OS choice to a client being the ultimate goal.

Release Note

SMB Attack is the term for how Ubuntu will try to gain installed desktop share in the SMB/SME environments, where Microsoft is typically the massively dominant choice.

It will include: * A new Gnome package to automatically parse and convert Windows UNC paths to Gnome-VFS network browse views. * Fixes to evolution-mapi so using Evolution with MS Exchange works fully and stable. * Fixes to gnome-control-center to ensure proxy support works correctly across the entire desktop. * Fixes to UbuntuOne to support proxy servers for all operations.


In an Enterprise environment there is typically an MS Exchange server and a proxy server. Documents generally are passed around in Office 2003 / 2007 / 2010 format and lots of files are exchanged using UNC paths in emails.

To use Ubuntu in these environments is a very challenging experience and usually ends up as being not worth the trouble when Windows SMB browsing has to be done manually, document formatting can be embarrassingly changed and emails are received by others as corrupted garbage.

For Ubuntu to succeed in these kinds of environments (which is potentially a massive market to tap into) it needs to improve in 3 main areas: * Improve Evolution to connect to Exchange and be able to perform comparably to Outlook, to the point of originating mails being almost indistinguishable from either program. * Work perfectly with various types of proxy servers. * Be able to use Windows UNC paths.

With these 3 major areas addressed, Canonical could be confident in pushing Ubuntu as an Enterprise Desktop, which is able to seamlessly slot-in to a Windows network and work without user irritation.

For document formatting, the previous modus operandi of all things .doc or .xls is no more and there is a state of flux due to some companies using Office 2010, some using Office 2007 and some using Office 2003 or earlier. This causes lots of issues with document compatibility, even in a Windows-only environment. This opens the door to OpenOffice, as it will introduce no more disparity into the mix than is already there.

User stories

Dan wants to share a file on a (non local) fileshare and send the link to several colleagues in an email. \\xyzserver\folder 1\folder 2\file.ext. Clicking on this link will open the file directly, based on the default application.

Emma wants to share her local folder, where are several subfolders and files located. Sending the link \\emmaspc\folder 1\ in an email will make the receiver able to click on it, opening the default file explorer application, showing the files and folders located in the folder 1 on Emma's PC.

Steve wants to share his local printer to several colleagues, so he shares the link in a spreadsheet, formatted text or PDF document.


Canonical is happy to step into this market.


You can have subsections that better describe specific parts of the issue.

Design one

Create a parser, what is an interface to the applications what has to do something with the links. For example the email client has one UNC link, and on the event of user click, it passes the UNC to the parser and converts it to the appropriate form, what is interpreted by the native Linux application. This parser passes the converted UNC link to the default application also. In this case if there are more application what can handle the link type, an application chooser window can appear as in Ubuntu, when opening a file, what has several handlers.

This design has two major parts:

  • Write a parser
  • * Identifies the UNC link type
  • * Converts the link to the appropriate form
  • * Opens the appropriate application with the parameter set
  • Implement the bridge in the native applications to the parser
  • Make native applications interpret and handle the UNC links


This section should describe a plan of action (the "how") to implement the changes discussed. Could include subsections like:

UI Changes

Should cover changes required to the UI, or specific UI that is required to implement this

Code Changes

Code changes should include an overview of what needs to change, and in some cases even the specific details.



  • data migration, if any
  • redirects from old URLs to new ones, if any
  • how users will be pointed to the new way of doing things, if necessary.

Test/Demo Plan

It's important that we are able to test new features, and demonstrate them to users. Use this section to describe a short plan that anybody can follow that demonstrates the feature is working. This can then be used during testing, and to show off after release. Please add an entry to for tracking test coverage.

This need not be added or completed until the specification is nearing beta.

Unresolved issues

This should highlight any issues that should be addressed in further specifications, and not problems with the specification itself; since any specification with problems cannot be approved.

BoF agenda and discussion

Use this section to take notes during the BoF; if you keep it in the approved spec, use it for summarising what was discussed and note any options that were rejected.

CategorySpec CategorySpec

Specs/SMBAttack (last edited 2011-03-13 20:09:05 by chronos-hun)