Tag Archives: small business server

cloud computing, microsoft, office 365

Notes from the field: Office 365 Cutover Migration for a small business and the mysteries of mail-enabled users

1 Comment

I assisted a small company in migrating from Small Business Server 2011 to Office 365.

SBS 2011 was the last full edition of Small Business Server, with Exchange included. It still works fine but is getting out of date, and Microsoft has no replacement other than full Exchange and multiple servers at far greater cost, or Office 365.

There must be hundreds of thousands of businesses who have done this or will do it, and you would expect Microsoft’s procedures to be pretty smooth by now. I have done this before, but not for a couple of years, so was interested to see how it now looks.

The goal here is to migrate email (I am not going to cover SharePoint or other aspects of migration here) in such a way that no email or other Oulook data in lost, and that users have a smooth transition from using an internal mail server to using Office 365.

What you do first is to set up the Office 365 tenant and add the email domain, for example yourbusiness.co.uk. You do not complete the DNS changes immediately, in particular the MX record that determines where incoming mail is sent.

Now you have a few choices. In the new Office 365 Admin center, in the Users section, there is a section called Data Migration, which has an option for Exchange. “We will … guide you through the rest of the migration experience,” it says.

If you select Exchange you are offered the Office 365 Hybrid Configuration Wizard. You do not want to use this for Small Business Server. It sets up a hybrid configuration with Exchange Federation Trust, for a setup where Office 365 and on-premises Exchange co-exist. Click on this image if you want to know more. I have no idea if it would work but it is unnecessarily complicated.

image

No, what you should do is go down the page and click “Exchange Online migration and deployment guidance for your organisation”. Now we have a few options, the main relevant ones being Cutover and Hybrid 2010. Except you cannot use Hybrid 2010 if you have a single-server setup, because this requires directory synchronization. And you cannot install DirSync, nor its successor Azure AD Connect, on a server that is a Domain Controller.

So in most SBS cases you are going to do a Cutover migration, suitable for “fewer than 2000 mailboxes” according to Microsoft. The SBS maximum is 75 so you should be fine.

Click Cutover Migration and you get to a nice migration assistant with 15 steps. Let’s get started.

image

So I did, and while it mostly works there are some gotchas and I am not impressed with the documentation. It has a combination of patronising “this is going to be easy” instructions with links that dump you into other documents that are more general, or do not cover your exact situation, particularly in the case of the mysterious “Create mail-enabled users” of which more below.

Steps 1-5 went fine and than I was on step 6, Migrate your mailboxes. This guides you to the Migration Batch tool. This tool connects to your SBS Exchange, creates Office 365 users for each Exchange mailbox if they do not already exist, and then copies all the contents of those mailboxes to the new mailboxes in Office 365.

image

While this tool is useful, I found I had what seemed to me obvious questions that the documentation, such as it is, does not address. One is, what do you do if one or more mailboxes fail to sync, or sync with errors reported, which is common. The document just advises you to look at the log files. What if you stop and then resume a migration batch, what actually happens? What if you delete and recreate a migration batch (as support sometimes advises), do you get duplicate items? Do you need to delete the existing users? How do you get to the Finalized state for a mailbox? It would be most helpful if Microsoft would provide detailed documentation for this too, but if it does, I have not found it.

The migration can take a long time, depending of course on the size of your mailboxes and the speed of your connection. I was lucky, with just 11 users it tool less than a day. I have known this tool to run for several days; it could take weeks over an ADSL connection.

Note that even when all mailboxes are synced, mail is still flowing to on-premises Exchange, so the sync is immediately out of date. You are not done yet.

The mysteries of converting to Mail-Enabled Users

I got to Synced after only a few hiccups. Now comes the strange bit. Step 7 is called Create mail-enabled users.

 

image

There are numerous problems with this step. It does not fully explain the implications of what it describes. It does not actually work without tweaking. The documentation is sloppy.

Do you need to do this step at all? No, but it does have some advantages. What it does is to remove (actually disconnect rather than delete) the on-premises mailbox from each user, and set the TargetAddress attribute in Active Directory, which tells Exchange to route mail to the TargetAddress rather than trying to deliver it locally. The TargetAddress, which is only viewable through ADSI Edit or command-line tools, should be set to the unique Office 365 email address for each users, typically username@yourbusiness.onmicrosoft.com, rather than the main email address. If I have this right (and it is not clearly explained), this means that any email that happens to arrive at on-premises Exchange, either because of old MX records, or because the on-premises Exchange is hard-coded as the target server, then it gets sent to Office 365.

Update: there is one scenario where you absolutely DO need this step. This is if you want to use ADConnect to synch on premise AD with Office 365, after doing the mail migration. See this thread and the comment:

“To covert on-premises mailboxes to mail-enabled users is required. When you convert on-premises mailboxes to mail-enabled users (MEUs), the proxy addresses and other information from the Office 365 mailboxes are copied to the MEUs, which reside in Active Directory in your on-premises organization. These MEU properties enable the Directory Synchronization tool, which you activate and install in step 3, to match each MEU with its corresponding cloud mailbox.”

The documentation for this step explains how to create a CSV file with the primary email addresses of the users to convert (this works), and then refers you to this document for the PowerShell scripts to complete the step. You will note that this document refers to Exchange 2007, though the steps also apply to Exchange 2010, and to a Staged Exchange migration, when you are doing a Cutover. Further, the scripts are embedded in the text, so you have to copy and paste. Further, the scripts do not work if you try to follow the instructions exactly. There are several issues.

First, this step seems to be in the wrong place. You should change the MX records to route mail to Office 365, and then leave an interval of at least a few hours, before doing this step. The reason is that once you convert SBS users to mail-enabled users, the Migration tool will not be able to re-sync their mailbox. You must complete a sync immediately before doing the conversion. The only way I know to force a sync is to stop and then resume the Migration Batch. Check that all mailboxes are synced, which only takes a few minutes, before doing the conversion. You may still lose an email if it arrives in the window between the last sync and the conversion, which is why you should change the MX records first.

Second, if you run ExportO365UserInfo.ps1 in the Small Business Server Exchange Shell, it will not work, since “By default, Import-PSSession does not import commands that have the same name as commands in the current session.” This means that when the script runs mailbox commands they run against the local Exchange server rather than Office 365, unless you use the –AllowClobber parameter. I found the solution was to run this script on another machine.

Third, the script still does not work, since, in my case at least, the Migration Batch did not populate the onmicrosoft.com email address for imported users. I fixed this with a handy script.

Note that the second script, Exchange2007MBtoMEU.ps1, must be run in the SBS server Exchange Shell, otherwise it will not work.

Bearing in mind all these hazards, you might think that the whole, not strictly necessary, step of converting to mail-enabled users is not worth it. That is perfectly reasonable.

Finishing the job

Bearing in mind the above, the next steps do not altogether make sense. In particular, step 11, which says to make sure that:

“Office 365 mailboxes were synchronized at least once after mail began being sent directly to them. To do this, make sure that the value in the Last Synced Time box for the migration batch is more recent than when mail started being routed directly to Office 365 mailboxes.”

In fact, you will get errors here if you followed Step 7 to create mail-enabled users. Did anyone at Microsoft try to follow these steps?

Still, I have to say that the outcome in our case was excellent. Everything was copied correctly, and the Migration Batch tool even successfully replicated fiddly things like calendar permissions. The transition was smooth.

Note that you should not attempt to point an existing Outlook profile at the Office 365 Exchange. Instead, create a new profile. Otherwise I am not sure what happens; you probably get thousands of duplicate items.

One puzzle. I did not spot any duplicates in the synced mailboxes, but the item count increased by around 20% compared to the old mailboxes, as reported by PowerShell. Currently a mystery.

Closing words

I am puzzled that Microsoft does not have any guidance specifically for Small Business Server migrations, given how common these are, as well as by the poor and inaccurate documentation as noted above.

There are perhaps two factors at play. One is that Microsoft expects businesses of any size to use partners for this kind of work, who specialise in knowing the pitfalls. Second, the company seems so focused on enterprises that the needs of small businesses are neglected. Note, for example, the strong push for businesses to use the Azure AD Connect tool even though this requires a multi-server setup. There is a special tool in Windows Server Essentials, but this does not apply for businesses using a Standard edition of Small Business Server.

Finally, note that there are third-party tools you can use for this kind of migration, in particular BitTitan’s MigrationWiz, which may well be easier though a small cost is involved.

microsoft, software, windows

Microsoft Small Business Server to Server Essentials R2: not a smooth transition

Recently I assisted a small business (of around 10 users) with a transition from Small Business Server 2003 to Server Essentials R2.

Small Business Server 2003 had served it well for nearly 10 years. The package includes Windows Server 2003 (based on XP), Exchange, and the rather good firewall and proxy server ISA Server 2004 (the first release had ISA 2000, but you could upgrade).

image

SBS 2003 actually still does more than enough for this particular business, but it is heading for end of support, and there are some annoyances like Outlook 2013 not working with Exchange 2003. This last problem had already been solved, in this case, by a migration to Office 365 for email. No problem then: simply migrate SBS 2003 to the latest Server 2012 Essentials R2 and everything can continue running sweetly, I thought.

Sever Essentials is an edition designed for up to 25 users / 50 devices and is rather a bargain, since it is cheap and no CALs are required. In the R2 version matters are confused by the existence of a Server Essentials role which lets you install the simplified Essentials dashboard in any edition of Windows Server 2012. The advantage is that you can add as many users as you like; the snag is that you then need CALs in the normal way, so it is substantially more expensive.

Despite the move to Office 365, an on-premise server is still useful in many cases, for example for assigning permissions to network shares. This is also the primary reason for migrating Active Directory, rather than simply dumping the old server and recreating all the users.

The task then was to install Server Essentials 2012 R2, migrate Active Directory to the new server, and remove the old server. An all-Microsoft scenario using products designed for this kind of set-up, should be easy right?

Well, the documentation starts here. The section in TechNet covers both Server 2012 Essentials and the R2 edition, though if you drill down, some of the individual articles apply to one or the other. If you click the post promisingly entitled Migrate from Windows SBS 2003, you notice that it does not list Essentials R2 in the “applies to” list, only the first version, and there is no equivalent for R2.

Hmm, but is it similar? It turns out, not very. The original Server 2012 Essentials has a migration mode and a Migration Preparation Tool which you run on the old server (it seems to run adprep judging by the description, which updates Active Directory in preparation for migration). There is no migration tool nor migration mode in Server 2012 Essentials R2.

So which document does apply? The closest I could find was a general section on Migrate from Previous Versions to Windows Server 2012 R2 Essentials. This says to install Server 2012 Essentials R2 as a replica domain controller. How do you do that?

To install Windows Essentials as a replica Windows Server 2012 R2 domain controller in an existing domain as global catalog, follow instructions in Install a Replica Windows Server 2012 Domain Controller in an Existing Domain (Level 200).

Note the “Level 200” sneaked in there! The article in question is a general technical article for Server 2012 (though in this case equally applicable to R2) aimed at large organisations and full of information that is irrelevant to a tiny 10-user setup, as well as being technically more demanding that you would expect for a small business setup.

Fortunately I know my way around Active Directory to some extent, so I proceeded. Note you have to install the Active Directory role before you can run the relevant PowerShell cmdlets. Of course it did not work though. I got an error message “Unable to perform Exchange Schema Conflict Check.”

This message appears to relate to Exchange, but I think this is incidental. It just happens to be the first check that does not work. I think it was a WMI (Windows Management Instrumentation) issue,  I did not realise this at first though.

I should mention that although the earlier paper on migrating to Server Essentials 2012 is obsolete, it is the only official documentation that describes some of the things you need to do on the source server before you migrate. These include changing the configuration of the internet connection to bypass ISA Server (single network card configuration), which you do by running the Internet Connection Wizard. You should also check that Active Directory is in good health with dcdiag.exe.

I now did some further work. I removed ISA Server completely, and removed Exchange completely (note you need your SBS 2003 install CD for this). Removing ISA broke the Windows Server 2003 built-in firewall but I decided not worry about it. Following a tip I found, I also used ntdsutil to change the DSRM (Directory Services Recovery Mode) password. I also upgraded the SBS AD forest to Server 2003 (it was on Server 2000), which is necessary for migration to work.

I am not sure which step did the trick, but eventually I persuaded the PowerShell for creating the Replica Domain Controller to work. Then I was able to transfer the FSMO roles. I was relieved; I gather from reading around that some have abandoned the attempt to go from AD in Server 2003 to AD in Server 2012, and used an intermediate Server 2008 step as a workaround – more hassle.

After that things went relatively smoothly, but not without annoyances. There are a couple to mention. One is that after migrating the server, you are meant to connect the client computers by visiting a special URL on the server:

Browse to http://destination-servername/connect and install the Windows Server Connector software as if this was a new computer. The installation process is the same for domain-joined or non-domain-joined client computers.

If you do that from a client computer that was previously joined to the SBS domain (having removed unwanted stuff like the SBS 2003 client and ISA client) then you are prompted to download and run a utility to join the new network. You do that, and it says you cannot proceed because a computer of the same name already exists. But this is that same computer! No matter, the wizard will not run, though the computer is in fact already joined to the domain.

If you want to run the connect wizard and set up the Essentials features like client computer backup and anywhere access, then as far as I can tell this is the official way:

  • Make sure you have an admin user and password for the PC itself (not a domain user).
  • Demote the computer from the domain and join it to a workgroup. Make sure the computer is fully removed from the domain.
  • Then go to the connect URL and join it back.

If you are lucky, the domain user profile will magically reappear with all the old desktop icons, My Documents and so on. If you are unlucky you may need manual steps to recover it, or to use profile migration tools.

This is just lazy on Microsoft’s part. It has not bothered to create a tool that will do what is necessary to migrate an existing client computer into the Server Essentials experience (unless such a tool exists and I did not find it; I have seen reports of regedit hacks).

The second annoyance was with the Anywhere Access wizard. This is for enabling users to log in over the internet and access limited server features, and connect to their client desktop. I ran the wizard, installed a valid certificate, used a valid DNS name, manually opened port 443 on the external firewall, but still got verification errors.

image

Clicking Repair is no help. However, Anywhere Access works fine. I captured this screenshot from a remote session:

image

All of the above is normal business for Microsoft partners, but does illustrate why small businesses that take on this kind of task without partner assistance may well run into difficulties.

Looking at the sloppy documentation and missing pieces I do get the impression that Microsoft cares little about the numerous small businesses trundling away on old versions of SBS, but which now need to migrate. Why should it, one might observe, considering how little it charges for SBS 2012 Essentials? It is a fair point; but I would argue that looking after the small guys pays off, since some grow into big businesses, and even those that do not form a large business sector in aggregate. Google Apps, one suspects, is easier.

An underlying issue, as ever with SBS, is that Windows Server and in particular Active Directory is designed for large scale setups, and while SBS attempts to disguise the complexity, it is all there underneath and cannot always be ignored.

In mitigation, I have to say that for businesses like the one described above SBS has done a solid job with relatively little attention over many years, which is why it is worth some pain in installation.

Update: A couple of further observations and tips.

Concerning remote access, I suspect the wizard wants to see port 80 open and directed to the server. However this is not necessary as far as I can tell. It is also worth noting that SBS Essentials R2 installs TS Gateway, which means you can configure RDP direct to the server desktop (rather than to the limited dashboard you get via the Anywhere Access site).

The documentation, such as it is, suggests that you use the router for DHCP. Personally I prefer to have this on the server, and it also saves time and avoids errors since you can import the DHCP configuration to the new server.

exchange, microsoft, sharepoint, virtualization, windows

Farewell to Microsoft Small Business Server

Microsoft has announced pricing and licensing for Windows Server 2012. A dry topic perhaps; but one which confirms the end of a product with which I am perhaps too familiar: Small Business Server. It is spelt out in the FAQ:

Q33. Will there be a next version of Windows Small Business Server 2011 Standard?

No. Windows Small Business Server 2011 Standard, which includes Exchange Server and Windows server component products, will be the final such Windows Server offering. This change is in response to small business market trends and behavior. The small business computing trends are moving in the direction of cloud computing for applications and services such as email, online back-up and line-of-business tools.

The next question confirms that there will not be a new edition of Small Business Server 2011 Premium either. The official replacement is Windows Server 2012 Essentials, which is in effect the next version of Small Business Server Essentials. This handles local Active Directory, file sharing, local applications, and a connector to Office 365. However there is a 25 user account limit, whereas SBS standard supported up to 75 users, so there will be some businesses who are now forced to choose between moving to Windows Server Standard, or ditching the local server completely (which is often impractical).

image

Microsoft is pinning the reason on cloud computing, which makes some sense. Now and again I am asked by small businesses what sort of technology they should adopt; and my answer in general is to point them at either Microsoft Office 365 or Google Apps.

It is not quite clear-cut. A Small Business Server can theoretically work out cheaper, if you presume that it will not require any external maintenance. That is rarely the case though, and for most people the cloud-hosted option will be both cheaper and less troublesome.

What if you do need on-premise Active Directory, Exchange and SharePoint, which are the core components of SBS? Technically, there are in my opinion better ways to do this than with SBS. While SBS has always been excellent value for money, it is over-complex because it crams onto one box applications which are designed to run on separate boxes. It does work, but if anything goes wrong it is actually harder to troubleshoot than when you have separate servers. I prefer to see one Hyper-V box with separate Virtual Machines (VMs) for each major function, than SBS running on bare metal. VMs are also more flexible, and easier to restore if the hardware breaks.

Farewell then to SBS. I will remember it with some affection though. Think back to the nineties, when most email was POP3, and most internet was dial-up. People had problems like losing emails, because they had been downloaded to a desktop PC and they were out and about with a laptop. Moving to Microsoft Exchange, for which Outlook is the client, was bliss by comparison. Email synchronised itself to all your PCs, you could work offline, and Outlook for all its faults became a one-stop application for calendar, contacts and messages.

The beauty of SBS was that you could get Exchange along with the benefits of a Windows domain – one central directory of users and the ability to assign permissions to file shares – at a price that was more than reasonable.

I also think of SBS as a reliable product, when correctly installed. When it does go wrong it is often due to users trying to do stuff that does not quite work, or other applications which get installed on the same box, or hardware faults which users have attempted to fix by messing around with Windows, or anti-virus software misbehaving (Sophos! Confess!).

Microsoft is doing the right thing though. The SBS bundle makes little sense today, and if you do still need it, you can stick with the 2011 edition for a few years yet.

exchange, microsoft, windows

Fixing a Small Business Server 2008 broken by updates

1 Comment

I had a call last night from a small business whose email no longer worked. They had applied updates to the server but Exchange had failed to restart.

Looking at the services it was easy to see why. All the Exchange services and certain others including the IIS web server were set to disabled:

image

The likely culprit was Update Rollup 5 for Exchange Server 2007 Service Pack 3 (KB 2602324) – or rather, the mechanism which applies the patch, since this seems to be an issue that others have run into as far back as 2008 with other Exchange patches, though it is rare:

I installed the Update Rollup 4 and did a reboot of my Exchange Server 2007. But since then, all my services are disabled. Is this a known issue?

My guess is that the patch disables the services in order to update the binaries and then, for some unknown reason not fixed by Microsoft over these last four years, fails to re-enable them.

It seems that no harm was done other than that the services were disabled, but how can you know which services are meant to be running, which should be set to manual, and which should stay disabled?

I contemplated doing a quick test install of SBS 2008 on a VM just  to see how it is set out of the box, but fortunately found this post by Susan Bradley which shows default SBS 2008 running services.

There were a few other things wrong.  SharePoint Services was raising event 5586:

Unknown SQL Exception 33002 occured. Additional error information from SQL Server is included below. Access to table dbo.Versions is blocked because the signature is not valid.

and there was the related event 33002 from the internal SQL Server used by SharePoint. The cause of this was SharePoint Services 3.0 Service Pack 3. When you apply a major update to SharePoint Services, you have to re-run the SharePoint Products and Technologies Configuration Wizard. This is by design, though it seems odd to me that you apply an update and it silently breaks the product it is updating until you run a further manual process. Of course the error itself does not give you much clue about what is really wrong.

The third major issue was a JRNL_WRAP_ERROR from the NTFrs File Replication Service. You have to be careful with this one, since the advised fix in the event log presumes the presence of a good replica elsewhere, which in the case of SBS is unlikely. See this article for details. With SBS which it is the sole domain controller you should set the BurFlags registry key to D4. Further comment on ServerFault here.

The incident reminds me of how prickly SBS can be. It is great value for what it does, but has all the complexity of Microsoft’s server stack plus the further disadvantage of being crammed onto one machine. I prefer a pseudo multi-server approach, even for small businesses, with at least two physical servers and separate VMs for Exchange, SharePoint, domain controller, backup DC on the other physical machine, and so on. Of course this has complexity of its own.

I would guess that when upgrade time comes around, companies like this will be looking carefully at Office 365. Or Google Apps; but the advantage of Office 365 is that you can make the transition from SBS with relatively little impact on users: just migrate the Active Directory, Exchange and SharePoint. You lose flexibility and some local performance, but hand over the maintenance issues to Microsoft.

microsoft, professional, virtualization, windows

Restoring an old Small Business Server 2008 backup: beware expired Active Directory

Seemingly tricky problems sometimes have simple solutions – but you have to find them first.

So it was with this one. I was asked to recover some emails from Small Business Server, from a backup that was about six months old. This SBS runs on Hyper-V using a proven backup system and I decided to restore onto a test system just to recover the emails. All went well until the first boot. The restored SBS went into a reboot cycle. Trying safe mode revealed the error:

STOP: c00002e2 Directory Services could not start because of the following error: A device attached to the system is not functioning. Error Status: 0xc0000001

The suggested fix for this is to boot into Directory Services Restore Mode. In my case this was not possible, because after the first failure the VM booted into Windows Error Recovery mode which does not offer Directory Services Restore Mode. Rather than try to get round this, I simply restored the server again, and took a snapshot before the first boot so I would not have to do so again.

I could now get into Directory Services Restore Mode, though note that you need to log on as .\administrator using the password set when SBS 2008 was installed. I tried some of the steps here with little success. The suggested ntdsutil commands did not work. I had to activate an instance, which by the way is ntds, and then got a message saying the operation failed because the system was in Directory Services Restore Mode and to try rebooting. I knew what the result would be.

In other words, I was getting nowhere. Then I found a user with a similar problem. The reason: Active Directory will not restore if it is older than the “tombstone lifetime”. This is nicely explained here. It is to do replication. Active Directory is designed to replicate between domain controllers, which means it has to keep a record of deleted items. If a particular instance is older than the tombstone lifetime, it could not replicate safely, hence the error message.

Well, kind-of. Note that the error message says, “A device attached to the system is not functioning”. If only it could have said, “Active Directory is too old”, that would have saved some time. Note also that SBS is often the sole domain controller, making the problem irrelevant. Note further that in my case I did not care a jot about replication, since all I needed was some emails.

Still, it gave me an easy solution. Just set the date back in Hyper-V and reboot. Everything worked fine.

In the end it did not cost me too much time, and doing this stuff in Hyper-V while getting on with your work during the slow bits is a lot more fun than when using real systems.

I do find it interesting though how these simple problems can surface as bewildering errors that lead you through a maze of obscure technical documents before you find the simple solution.

.net, microsoft, professional, sharepoint, windows

Remote access to files in Microsoft Small Business Server 2011

Among the most interesting features in the new Small Business Server 2011 standard edition – I suspect it is in the Essentials version as well – is the ability to access shared folders remotely via a web application.

This is actually a feature borrowed from Windows Home Server, which also exposes shared folders in its remote access web application.

Note this is different from SharePoint, which is also available in SBS. SharePoint stores files in a SQL Server content database and publishes them in document libraries. Shared Folders by contrast are simple file shares. Although they lack the rich features of SharePoint, such as discussions, or check in and check out, they are faster and more convenient when all you want to do is to share files. Another benefit is that on the local network you can access shared folders directly with Windows Explorer. This can also be done with SharePoint, but under the covers it uses WebDAV – web distributed authoring and versioning – which is slower and can be tricky to get working, especially on Windows XP. SharePoint is also less suitable for files of types that it does not recognise, whereas a shared folder will accept anything you care to put into it.

While these may seem subtle distinctions, in practice they are not, and the matter of SharePoint versus shared folders is one that some businesses struggle with.

Now that you can publish shared folders through the Remote Web Access web site, this issue will be less pressing, since remote access without the need for VPN (virtual private network) is often the key reason for moving files into SharePoint.

The Remote Web Access site is not itself a SharePoint site; it is an ASP.NET application that you can find in C:\Program Files\Windows Small Business Server\Bin\WebApp\RemoteAccess. I noticed two ASP.NET user controls, one called filesgadget.ascx and one called richupload.ascx.

If you browse to this site, you can access folders and files in the SBS Shares to which you have access, controlled by NTFS permissions. The file sharing application will pick up any shared folders on the server. When you open a folder, the files are listed in the browser with options to upload, download, delete, rename, copy, cut or paste.

image

If you choose Upload, you can add documents by dragging them into the browser.

image

I also tried the site in Google Chrome. It worked, though not the drag-and-drop file upload. You can still upload files using a standard file chooser.

This looks to me like a great and overdue feature for Small Business Server. The only snag I can foresee is that some users may still find the SharePoint vs Shared Folder choice confusing and wonder why documents in the “Internal web site” are presented differently and with more features than those in shared folders. It may still be difficult to decide which to use; but at least the choice will no longer be driven solely by whether remote access via the browser is required.

cloud computing, microsoft, professional, Web

Microsoft’s muddled licensing for Office Web Apps

1 Comment

I’ve been reviewing Microsoft’s Small Business Server 2011 – mainly the standard edition as that is the one that is finished. The more interesting cloud-oriented Essentials version is not coming until sometime next year.

In its marketing [pdf] for SBS 2011 Microsoft says:

Get things done from virtually wherever and whenever. With Office Web Apps (included in SharePoint Foundation 2010), users can view, create, and edit documents anyplace with an Internet connection.

This appears to be only a half-truth. You can install Office Web Apps into SharePoint Foundation 2010, but it is not included in a default install of SBS 2011 Standard, and as far as I can tell the setup for it is not on the DVD. If you try to download it, you will find it is only available through the Volume Licensing Service Center, and that you require a volume license for Microsoft Office to get it. You can also get it through TechNet, but this is for evaluation only.

The Office Web Apps site states:

Business customers licensed for Microsoft Office 2010 through a Volume Licensing program can run Office Web Apps on-premises on a server running Microsoft SharePoint Foundation 2010 or Microsoft SharePoint Server 2010.

and it also appears that each user requires a volume license for desktop Microsoft Office in order to use it. In other words, the Client Access License for Office Web Apps is a volume license for Office. You cannot purchase a volume license for 5 users, and then have everyone in your 50-person organisation use it.

This approach to licensing makes no sense. In fact, I’m not sure it is even internally consistent. Part of the web app concept is that you could, if need be, walk up to a PC in an internet cafe, log in to SharePoint, and make a quick edit to a Word document. You are not going to ask the management “is this machine correctly licensed for Office Web Apps?”

What if you are using Linux, or an Apple iPad (it almost works), or a RIM PlayBook, or some other device on which Office cannot be installed? These are scenarios where Office Web Apps is particularly useful; Microsoft cannot expect users to buy a license for desktop Office for machines which cannot run it.

Note Office Web Apps applications are severely cut-down in comparison to the desktop editions. It is not even close to the same thing. Further, Microsoft lets anyone in the world use Office Web Apps for free – provided it is on SkyDrive and not on a locally installed SharePoint.

Microsoft is also happy to give users of Office 365, the forthcoming hosted version of server apps including SharePoint, access to Office Web Apps:

Work from virtually any place and any device with the Office Web Apps

I’m guessing that somewhere in Microsoft the powerful Office group is insisting that Office Web Apps is a feature of the desktop product. Anyone else can see that it is not; it is a feature of SharePoint. Excluding it from SBS 2011 by default does nothing except to complicate matters for admins – and it is a fiddly install – thus reducing the appeal of the product.

Incidentally, I see nothing unreasonable about Microsoft charging for an on-premise install of Office Web Apps. But it should be licensed as a web application, not as a desktop application.

For more on this see Sharon Richardson’s post and Susan Bradley’s complaint.

microsoft

Microsoft removes Drive Extender from new Windows Home Server, users rebel

3 Comments

Microsoft’s Windows Home Server has a popular feature called Drive Extender [Word docx] which lets you increase storage space simply by adding an internal or external drive – no fussing with drive letters. In addition, Drive Extender has some resilience against drive failure, duplicating files stored in shared folders when more than one drive is available.

Recognising the usefulness of this feature for business users as well as in the home, Microsoft prepared a significantly upgraded Drive Extender for the next version of Windows Home Server, code-named Vail, and for new “Essentials” editions of Small Business Server (SBS) and Storage Server. Anandtech has an explanation of the changes, necessary to support business features such as the Encrypted File System.

The new version is more complex though, and it seems Microsoft could not get it working reliably. Rather than delay the new products, Microsoft decided to drop the feature, as announced by product manager Michael Leworthy. Note the rating on the announcement.

image

Part of the problem is that rather than discuss difficulties in the implementation, Leworthy presented the decision as something to do with the availability of larger drives:

We are also seeing further expansion of hard drive sizes at a fast rate, where 2Tb drives and more are becoming easy accessible to small businesses.  Since customers looking to buy Windows Home Server solutons from OEM’s will now have the ability to include larger drives, this will reduce the need for Drive Extender functionality.

He added that “OEM partners” will implement “storage management and protection solutions”.

Unfortunately this was a key feature of Windows Home Server. The announcement drew comments like this:

My great interest in Vail has just evaporated.  Drive Extender is the great feature of Home Server, and what my personal data storage is based around.  I have loved owning my WHS but unfortunately without DE I will be looking for other products now.

A thread (requires login to WHS beta) on the beta feedback site Microsoft Connect attracted thousands of votes in a couple of days.

 image

One of the concerns is that while Drive Extender 2 may be needed for the business servers, the version 1 is fine for home users. Therefore it seems that the attempt to bring the technology to business servers has killed it for both.

The SBS community is less concerned about the issue than home users. For example, Eriq Neale says:

While I can see how the Home Server folks are going to lament the loss of DE from their product, as cool as it is, removing that technology removes a LOT of roadblocks I was expecting for Aurora and Breckenridge, and that’s good news for my business.

though Wayne Small says:

I know that a few of my fellow MVPs were told of this recently and sworn to secrecy under our NDA, and we honestly were dumbstruck as to the fact it had been cancelled.  I can only assume that the powers that be at Microsoft know what they are truly doing by removing this feature.  On the flip side however, it means that any server backup or antivirus product that worked with Windows Server 2008 R2 will now most certainly work with SBS 2011 Essentials without modification!  See – there is a silver lining there somewhere.

What should Microsoft do? I guess it depends on how badly broken Drive Extender 2 is. Perhaps one option would be to keep Drive Extender 1 in Vail, but leave it out of the business servers. Another idea would be to delay the products while Drive Extender 2 is fixed, presuming it can be done in months rather than years.

Or will Microsoft ignore the feedback and ship without Drive Extender at all? Microsoft may be right, in that shipping a server with broken storage management would be a disaster, no matter how much users like the feature.

microsoft

Small Business Server “Aurora” based on Windows Home Server and will have hooks to the cloud

The most interesting session at TechEd in New Orleans last month was one I could not talk about until today. It concerned the next version of Small Business Server, no date announced yet. The next SBS will come in two editions. SBS 7.0 will be conceptually similar to today’s SBS, but updated to Server 2008 R2, Exchange 2010 and so on.

SBS code-name “Aurora” is the compelling one though. It is based on Windows Home Server (or at least the next version of WHS, “Vail”, but with Active Directory added. There are no other apps; you are expected to use cloud services.

The reason this matters is Microsoft’s work on federated Active Directory. What this means is that your local SBS simply manages users, computers and file shares, but the same user accounts also work on cloud-hosted services such as Exchange or SharePoint – or any others that support Active Directory federation.

I love this concept; it is exactly the right thing for SMEs who need to run a properly managed Windows network while using hosted email and other cloud services.

image

Questions remain of course. Will services other than Microsoft’s own BPOS or third-party hosted Exchange and SharePoint support SBS federated Active Directory? And will Microsoft and its partners really steer small businesses in this direction, or focus on SBS 7.0?

More details in this article on The Register.

PS This version of SBS is not too far removed from what I asked for in February 2006.

exchange, microsoft

Exchange 2007: ESEUTIL beats the wizard

3 Comments

Today I was asked to help find missing email in Small Business Server 2008, in other words Exchange 2007. Somehow, thousands of emails had disappeared from a user’s mailbox. They were there a couple of days earlier, so we restored a backup. The procedure is nicely explained by John Bay. You restore the Exchange database to a temporary directory, leaving Exchange up and running. Then you mount the restored backup into a “recovery storage group”, from where you can merge items from the recovered mailbox into the live one.

All went well, until the point where you mount the restored backup. The database would not mount. The event viewer said it was in an inconsistent state. Bay anticipates this, and suggests using the Exchange Troubleshooting Assistant to repair the database. The repair chugged away and completed; but the database still would not mount. I tried again, same result.

I gave up on the Assistant and reverted to the traditional command-line tools. I used the sequence:

ESEUTIL /P

ESEUTIL /D

ISINTEG

running against the recovered database. The first does a repair; the second defragments; and the third runs integrity checks and applies fixes.

Now, you would have thought that the Troubleshooting Assistant would use these very same tools underneath its pretty GUI, but that cannot be the case. Apart from anything else, ESEUTIL /P took much longer than the Assistant. In particular, it appeared to hang while doing something mysterious called Deleting Unicode fixup table.

image

It carried on saying this for around 7 hours. There was evidence that the process was still alive though, so I left it be.

It worked. I ran the other two commands, mounted the database, and merged the mailbox to recover about 4,000 emails.

image

The question remains: where did the emails go? All I know is that the problem coincided with a newly installed Windows and Outlook, which I’m guessing is significant.