Public beta of Office 2010 and SharePoint 2010 next month

The public betas for Office 2010, Project 2010, Visio 2010, and SharePoint Server 2010 will arrive in November 2009.

The public betas for Office 2010, Project 2010, Visio 2010, and SharePoint Server 2010 are slated for this November, Microsoft CEO Steve Ballmer today confirmed at the SharePoint Conference 2009. Given the name of the conference, Ballmer focused on revealing some of the new SharePoint 2010 capabilities for the first time, but also made sure to mention that SharePoint Server is one of the fastest-growing products in Microsoft’s history, with over $1.3 billion in revenue (a 20 percent growth over the past year).

Ballmer highlighted the following features and capabilities during his keynote:

  • A new ribbon user interface that makes end users more productive and customization of SharePoint sites easy
  • Deep Office integration through social tagging, backstage integration and document life-cycle management
  • Built-in support for rich media such as video, audio, and Silverlight, making it easy to build dynamic Web sites
  • New Web content management features with built-in accessibility through Web Content Accessibility Guidelines 2.0, multilingual support and one-click page layout, enabling anyone to access SharePoint Server sites
  • New SharePoint tools in Microsoft Visual Studio, giving developers a premier experience with the tools they know and trust
  • Business Connectivity Services, which allow developers to connect capabilities to line-of-business data or Web services in SharePoint Server and the Office client
  • Rich APIs and support for Silverlight, representational state transfer (REST) and Language-Integrated Query (LINQ), to help developers build applications fast on the SharePoint Server platform
  • Enterprise features in SharePoint Online such as Excel Services and InfoPath Forms Services, which make it simple to use, share, secure and manage interactive forms across an organization
  • The addition of two new SharePoint SKUs for Internet-facing sites, including an on-premises and hosted offer

If any of that strikes your fancy, you’ll want to watch the following video (Silverlight required):

The most ambitious goal Microsoft is striving for with Office 2010 is making it available via a familiar experience across the PC, phone, and browser. Office 2010 is the first release of the productivity suite that will come in 32-bit and 64-bit flavors and on one DVD no less.

PerformancePoint: BI for the masses.

Microsoft wants to bring BI to the masses and based on customer feedback they decided to put it together with the next version of SharePoint. They have decided to consolidate the scorecard, dashboard and analytical capabilities from Office PerformancePoint Server into Microsoft Office SharePoint Server Enterprise and rebrand them as PerformancePoint Services for SharePoint. Overall an equally good and bad thing in my opinion.

  • Good, because it will allow people to use BI with their SharePoint environments.
  • Bad, because it will allow people to use BI with their SharePoint environments

More information here:

Getting ready for SharePoint Server 2010?

The requirements are known so you have an easy starting point, ensuring your hardware is 64-bit as:

  1. SharePoint Server 2010 will be 64-bit only.
  2. SharePoint Server 2010 will require 64-bit Windows Server 2008 or 64-bit Windows Server 2008 R2.
  3. SharePoint Server 2010 will require 64-bit SQL Server 2008 or 64-bit SQL Server 2005.

If it is not, you will at some point need to move it. A great place to start the process of learning is on Technet, Migrate an existing server farm to a 64-bit environment (Office SharePoint Server 2007)

Things can get complicated after that point. Do you have an existent environment?

If yes

  • Deploy Service Pack 2 and take a good look at the SharePoint 2010 Upgrade Checker that is shipped as part of the update. The Upgrade Checker will scan your SharePoint Server 2007 deployment for many issues that could affect a future upgrade to SharePoint 2010.

If no

  • Get to know Windows Server 2008 with SharePoint 2007, this post is a great starting point.

Enabling OpenType Ligatures in Word 2010

Microsoft has added support for OpenType ligatures in Microsoft Word 2010 (Word 14).

To enable OpenType ligatures:

  1. right-click on some text
  2. select Font
  3. select the Advanced tab
  4. select Standard Only from the Ligatures combo box. (This will enable standard ligatures, such as fi and ffi.)

You can also select from a number of other sets of ligatures if you have the appropriate fonts installed. As well as stylistic sets, number forms, and change up the number spacing.

You may disable these OpenType features entirely by:

  1. open Word Options
  2. select the Advanced tab
  3. check Disable OpenType Font Formatting Features under the Layout Options that are right at the bottom.

Nifty: Microsoft Business Data Catalog Definition Editor for Microsoft Office SharePoint Server 2007

Ah Microsoft, you giveth and you taketh.

The Microsoft Business Data Catalog Definition Editor for Microsoft Office SharePoint Server 2007 aka MSBDCDEFMOSS2007 (all me…) is a nifty yet hobbled tool fresh(ish) from Microsoft. In brief its features include:

  • Underlying XML is abstracted by the design surface and properties window
  • Drag and drop web methods, tables, or views to create line of business (LOB) connections.
  • Entities and methods are created automatically from database metadata and WSDLs.
  • Additional method instances can be added to further enhance the database or web service connection.
  • Method instances can be tested from within the tool, enabling incremental development of LOB connections

That said… Here’s the catch. (For now I hope…)
The tool is unusable with SQL Server 2005/2008 schemas… So, you cannot use it against AdventureWorks, BUT you can use it against AdventureWorksDW. If you dare to try, you will be rewarded with a “Could not process Table ‘….’. Also, make sure you have SELECT Rights on the Table/VIEW”.

Helpful links

How much of a letter can be removed while maintaining readability?

How much of a letter can be removed while maintaining readability? Ecofont have a solution that uses up to 20% less ink. It works reasonably well so long as your expectations are kept within reasonable boundaries. Ecofont is compatible with Mac OS X, Windows, and Linux, and works just fine in OpenOffice, AppleWorks, and MS Office 2007.

The holes are not visible to the naked eye when you use it at the normal point size e.g. 10 or 12. Here is an example of it at size 12.

So, it’s not perfect and similar results may be obtainable by tweaking your printers settings… Ecofont is probably designed with ink gain in mind. Those tiny holes will fill up once the ink soaks into the paper. Question is, how will it act on coated stock, or when dry toner is used instead of ink?

Free to download, free to use.

So go get it and help save a tree. Or two.

How solution deployment has changed development with SharePoint technologies


Anyone who is familiar with development & deployment of custom solutions on SharePoint Portal Server 2003 or Windows SharePoint Services will probably agree when I say there are certain areas lacking in the end to end process.

For example, here is a high level generic step by step process that usually happens:

  1. Spec written (some people seem to think this step is optional)
  2. Developer develops code etc… Usually on a stand-alone, single server SharePoint environment. (I personally use a VPC for all development these days)
  3. Developer packages code into an installer if you are lucky
  4. Testing
  5. Hand off to production people who go and install it on the server(s).

This would normally be really easy right? Well, in SharePoint land there are many areas where “things” need to be done during an installation. Some of these are (but not limited to):

  • Assembly deployment. GAC or BIN
  • Web.config changes. Additions to the safe controls list, CAS security policies,
  • Resource files like images,
  • Dwp files
  • Site definitions (list definitions etc…)

Depending on how your development team packaged these would depend on how much work you had to do to deploy them.

To make matters worse, depending on your physical SharePoint farm you might need to do install steps on each server. This brought in complexity around what servers had what versions at what time etc… A nightmare if you were managing a large farm with many servers.

How we make this better in MOSS and WSSv3:

In MOSS we have a good solution to all of this called the Solution Framework. Here is a little summary about what this is:

“The Windows SharePoint Services (WSS) solution framework provides a way to bundle together all of the components for extending SharePoint in a new file called a solution file (a CAB-based format with a WSP extension). A solution is a deployable, reusable package that can contain a set of features and site definitions, templates, Web Parts, and assemblies that you can apply to a site, and individually enable or disable.” – WSS SDK

Not only this but the Solution Framework takes care of deploying the solution to ALL front end web servers in the farm without the admin having to go to each box to do this manually!

You can:

  • Deploy the Solution package to the farm
  • Retract the Solutions package
  • When a new web server is added, automatically deploy the solution to it
  • Deploy new versions of the Solution

Practical example:

In the system I talked about in “Application Development on MOSS & WSSv3” we are using a Solution package to deploy:

  • A custom Site Definition
  • 6 Feature Definitions (another new MOSS technology) that are:
    • Custom Workflows x2
    • Timer Job
    • Content Type
    • Custom List definition
    • Custom Site Columns definition
  • Web part
    • SafeControls list entry

Note: I won’t talk about Features or how to create them; Todd has a good post on that subject here:

[Updated] This means when we want to deploy this solution to a new farm we simply use the STSADM -addsolution -filename to upload the solution to the farm. Once uploaded you can simply to into the “Solution management” section under the “Operations” tab in the Central Administration Site, and deploy that solution.

Once it is uploaded we can then choose to Deploy that solution.

This gives you options on when you want the deployment to take place and to what web applications. (In the shot above I had an assembly being deployed to the GAC, hence the warning)

Although all this will be/is documented in the WSS SDK, I thought I quickly go over how to make a solution file.

Consists of:

  • A CAB file containing
    • A Manifest.xml file
    • All the files for the Features etc… that make up your solution

Below is a cut down sample XML manifest.xml file for the example I used above (highlighted text is comments):

< ?xml version="1.0" encoding="utf-8" ?>
< xmlns="" solutionid="{79d1a62e-3627-11db-963e-00e08161165f}" resetwebserver="TRUE">

< deploymenttarget="GlobalAssemblyCache" location="Foo.Sharepoint.WebpartsFoo.SharePoint.WebParts.dll">
< assembly="Foo.Sharepoint.Webparts, Version=, Culture=Neutral, PublicKeyToken=63cce650e8605f5d" namespace="Foo.Sharepoint.Webparts" typename="*">
< /SafeControls>
< /Assembly>
< deploymenttarget="GlobalAssemblyCache" location="Foo.Sharepoint.Timer/Foo.Sharepoint.Timer.dll">
< /Assemblies>


< location="Foo.Sharepoint.TimerFeature.xml">

< location="Foo.CustomTypeFeature.xml">

< location="Foo.FooLibraryFeature.xml">

< location="Foo.ColumnsFeature.xml">

< location="Foo.Workflow.ProcessFooFeature.xml">

< location="Foo.Workflow.ProvisionFooFeature.xml">

< /FeatureManifests>

< location="FOO">
< location="1033XMLWEBTEMPFoo.XML">
< /SiteDefinitionManifest>
< /SiteDefinitionManifests>
< /Solution>

Then you package this up along with all your Feature files into a CAB file with a “.wsp” extension. In short each feature goes into a sub-dir in the CAB that matches the path you have in the Manifest.xml file. You can use cabmake.exe to do this, or any other tool you like.

Then you are ready to go and deploy!

Although this is probably a little more work to begin with, your deployment team will thank you for it immensely.

Will Office 14 be ready for release in 2009?

In late July it was suggested that Office 14, the codename for the successor to Office 2007, would be released in either late 2009 or early 2010. This led to speculation that the next version of Office would be simultaneously released with Windows 7, much like Office 2007 and Vista were.

Blogger Stephen Chapman recently posted a screenshot he obtained in July 2008, suggesting that Office 2009 would indeed be released this year:

However, this information is now outdated, and Microsoft still has not started the Office 14 beta program. Most Windows 7 testers may not have received any builds as of yet, but select testers have, many builds have already leaked, and a public beta is supposed to be released very soon (at latest Friday).

On the other hand, Office 14 does not even have leaked screenshots yet, let alone a private or public beta. For this reason, I find it doubtful that Office 14 will be released simultaneously with Windows 7, especially given how quickly development for Vista’s successor seems to be going. Nevertheless, the beta program for an office suite can be much shorter than that of an operating system, so there is still hope.