Joel's SharePoint Architect Blog

SharePoint 2013 Training, Architecture, Administration and Development

Subscribe Subscribe  View Joel Jeffery's profile on LinkedIn
joelblogs.co.uk | joelj.co.uk | joeljeffery.co.uk | jfdiphoenix.co.uk

Posts Tagged ‘MOSS’

A recurring question among my students and some of my clients is the mysterious relationship between WSS 3.0 and MOSS 2007: when might you choose one product over the other?

Popular Misconception #1: “I can’t have MOSS and WSS. They’re mutually exclusive.”

Simply put, MOSS is a superset of WSS.

WSS 3.0 – Windows SharePoint Server – is the core site provisioning engine and development framework which is licensed at no further cost if you have Windows Server 2003/2008.

WSS provides the main site provisioning functionality – the engine for turning templates and definitions into a new instance of a site. This allows you as an administrator to download, design or buy a site definition or template, and then create sites based on those on demand.

WSS also provides the feature framework. This allows developers to package up reusable components as units called Features. As an administrator, you can once again download, design or buy suitable Features from various different vendors. Features wrap up things such as Web Parts – the composable on-screen unit of functionality that you can rearrange and place on different WSS pages within a site.

There are a number of brilliant features that WSS has out of the box. Wiki, Blog, Document Libraries, Calendars, Tasks and Lists to name but a few.

From a developer perspective, WSS is ASP.NET with a whole load of useful framework add-ons (such as being able to create Lists and Libraries without writing code) that enables me to deliver useful collaborative web applications quicker and more reliably.

Microsoft Office SharePoint Server 2007 – MOSS – on the other hand, is the product with a separate SKU and price tag. It can cost a few thousand per server for minimal functionality, all the way up to £30K and above for other features such as an public-facing Internet site.

MOSS, at its heart, is just a collection of really cool features. Some more valuable than others:

Business Data Catalog – this allows a “zero coding” solution to republish existing line of business apps (Siebel, SAP, etc – or even any home-grown app) and expose it in new ways through SharePoint. It also allows you to configure how you’d like to make that data searchable.

Excel Services – everything from Excel Web Access :- server controlled, HTML only, browser friendly, read only access to your Document Library of corporate spreadsheets; through to Excel Web Services:- a fantastic way of scalably running business logic tied up in spreadsheets on the server, even using “grid” computing (the HPC initiative from Microsoft).

InfoPath Forms Server – InfoPath forms rendered as ASPX (HTML) in the browser with pretty high fidelity. InfoPath is a great environment for less technical users to create extremely functional forms using the InfoPath Office 2007 client. It’s also a great platform for developers to use to via Visual Studio 2008. These can be used for data capture, interacting with workflow and driving business processes.

Records Center – a fully featured records management server complete with a routing engine for documents. You only need one of these in your organisation (unless your taxonomy demands different) but documents can be sent to it from an WSS/MOSS server on your estate.

My Sites – Web 2.0 features for the Enterprise; lets users create a profile page for themselves that can make visible a user’s colleagues, documents they’ve created, free-busy information and a whole load more.

Audiences – You can also target content to specific audiences, showing different content for different types of user. An audience is a set of rules that define things like “member of the Sales group in AD” or “users with ‘Marketing’ in their job title”. A timed job turns these rules into lists of real people, and the Web Part framework allows you to specify target audiences for content.

The list of features goes on…

Popular Misconception #2: “I only need one feature from MOSS, so I need to buy it all.”

Only some of these features are so ground breaking that you couldn’t build them yourself. In theory, you could write them as Features yourself on top of WSS 3.0 – but I find that Microsoft has more Research & Development dollars than I have, so it often makes sense to go with MOSS features where appropriate.

If you genuinely only require a subset of these features, then it comes down to a cost-benefit analysis. If you could write a feature yourself for substantially less than the cost of MOSS, it may be worthwhile to build the functionality you require as a bespoke, custom software development.

Popular Misconception #3: “If I need any degree of functionality out of the box, I’ve got to go with MOSS.”

While you’re investigating, it’s worth checking out a few giveaways from Microsoft:

The Core Application templates from Microsoft -
http://www.microsoft.com/downloads/details.aspx?familyid=C1039E13-94DA-4D7D-8CAE-3B96FA5A4045&displaylang=en

The “Fantastic Forty” / “Fantastic 40” WSS templates from Microsoft -
http://technet.microsoft.com/en-us/windowsserver/sharepoint/bb407286.aspx

The “Splendid Seven” / “Splendid 7” MOSS templates from Microsoft -

http://office.microsoft.com/en-us/sharepointserver/HA102147321033.aspx

These give you a lot of functionality; some require WSS only, some require MOSS. A couple of screenshots follow.

WSS Business Performance Reporting Site Template - Click to Zoom! MOSS Sales Account Manager Template - Click to Zoom!
Business Performance Reporting template in WSS Sales Account Manager My Site Template in MOSS

If you’d like to see some of these in action, the Fantastic Forty are installed live at www.wssdemo.com for you to play with.

Technorati Tags: Fantastic 40, Fantastic Forty, Features, Microsoft, MOSS, SharePoint, SharePoint Architecture, Splendid 7, Splendid Seven, WSS

I’m not sure how popular this misconception is, but it’s worth putting to bed. This time I’m going to try to clear up some misunderstandings about the relationship between WSS and the MOSS Records Center.

Popular Misconception #1: “I’ve seen a configuration screen for Records Management somewhere on my WSS server – that means there’s got to be some Records Management functionality built in…”

Configure Connection to Records Center - Click to Zoom!

Although it is true that you can configure something that looks like Records Management, Windows SharePoint Services 3.0 does not contain Records Management functionality. WSS only has the hooks that allow you to send documents in a library to an already existing Records Center on an appropriately configured MOSS 2007 server. If you want Records Management, then you need Microsoft Office SharePoint Server 2007, which, remember, is a separate SKU and carries a significant price tag.

On a WSS server, “Central Admin –> Application Management –> Configure Connection to Records Center” lets you specify (for your whole Web Application) the location of a MOSS Records Center. Specifically, you configure the URI of the Official File web service on that server.

What this does for your WSS Web Application is one thing: it enables an extra item in the Send To context menu in document libraries so you can now “right-click” a document and send it to the Records Center you set up previously.

Popular Misconception #2: “I can only send documents to a Records Center on the same server.”

This is absolutely not the case. When you configure the URL property in the “Configure Connection to Records Center” admin page, you’re specifying the full path to an Official File web service on any server. As long as the URL is reachable and suitably configured, the target server can even be on a different network. A common scenario is to have WSS sites on departmental servers in your organisation, and then a central Records Center on a MOSS server at the enterprise level. Once you’ve configured the Send To menu through the above admin page, you can send documents from WSS servers to MOSS Records Centers even when they’re hosted on different physical servers.

Popular Misconception #3: “Now I’ve set up Records Center and enabled the Send To menu, users can easily add turn documents into immutable records in the Records Center.”

I’m afraid not. Although the term “Send To Menu” conjures up images of right-clicking on the desktop, the WSS “Send To” menu is a lot less accessible. To send a document to a Records Center the user has to:

  1. Upload or create a document in a document library
  2. Click the context menu on the document
  3. Chose Send To –> <INSERT RECORDS CENTER NAME HERE>
  4. Fill in any missing details, content types and required fields

Sending a Document to the Records Center - Click to Zoom!

If your starting point is a document on the user’s desktop, that’s quite a few mouse clicks. As a developer, you do have some options. Remember that Records Center URL you configured on the admin screen up there? That’s the Official File web service – and it’s just a plain old SOAP service. You can consume that in your own code. There’s nothing to stop you writing a Word Add-In that lives on the Ribbon Bar to allow a user to send the currently open document to the Records Center in one click. You could even iterate over document properties or bookmark fields before sending it, and then set those properties (including a MOSS Content Type for the resulting document) in your call to the Official File web service.

In fact, I think I might just do that. Watch this space.

Technorati Tags: Document Library, MOSS, Official File, Records Center, Records Management, Send To Menu, SharePoint, SharePoint Architecture, WSS

SharePoint 2007 Experiences from the Field

My good friend and colleague Cédric Oster has an excellent blog on his experiences with SharePoint 2007, InfoPath 2007 and more. Cédric is a SharePoint consultant of quite some standing.

You can read Cédric’s SharePoint Blog for his latest writing. I’ve just read his piece on SharePoint database growth rates, and how to deal with them. Very sound advice – Cédric writes:

“To free up space manually: after a full backup you can shrink and truncate the log file to any size you need by doing the following:

  • Open SQL Server Management Studio
  • Select the database you want to shrink the log file (e.g. MOSS_Intranet_Content)
  • Click the “New Query” button
  • and run the following command:
    dbcc shrinkfile (<LOGICAL LOG FILE NAME>,<SIZE IN MB>,truncateonly)

for example: dbcc shrinkfile (MOSS_Intranet_Content,2,truncateonly)

This applies to the Content Databases but also the Configuration and Search Databases.”

I should point out that this principle also applies to SQL Server development in general. If you’re developing using SQL Server, very often backup, restore and maintenance can be all too easily forgotten. The best side effect of which is that you end up with an enormous log file, or performance would eventually be degraded. The worst side effect could be that you might not have a database backup and maintenance schedule, which could put your data at risk.

Microsoft System Center Data Protection ManagerHere’s what MSDN has to say about DBCC SHRINKFILE. Similarly, I should point you at Joel Oleson’s Blog – another noteworthy SharePoint blogger. He has an excellent article on Best Practice for SharePoint Backups.

I would side with Joel here, not just because we share a name, but because I, too, really rate Microsoft System Center Data Protection Manager as the best mechanism for WSS and MOSS backups. Here’s an informative webcast from Microsoft on backing up MOSS with DPM. This may well become a topic for a future blog entry for me.

Technorati Tags: Backup, DBCC, DPM, Microsoft, MOSS, SharePoint, SharePoint Administration, SHRINKFILE, SQL Server, System Center, WSS

Here is the second in a series of impromptu hints and pointers for Microsoft Office SharePoint Server 2007.

InfoPath 2007InfoPath. Have you used it? You’re not still using Microsoft Word and form fields, are you? In addition to being a great alternative to locked Word documents for departmental form filling, InfoPath is a great development platform.

You can use InfoPath forms for a number of tasks: capturing form data and saving it as a document (of course); uploading into SharePoint to start a workflow; using custom InfoPath forms to allow admins to configure reusable workflows; rendering in a browser via ASP.NET.

Which brings us to:

Popular Misconception #1 – “InfoPath forms need InfoPath installed on the desktop. We don’t have control over what’s installed on our users’ PCs, so we can’t use InfoPath.”

Admittedly, the user experience is better when InfoPath forms are opened in InfoPath Client 2007, but you can publish a form with a high degree of fidelity either through a browser-enabled SharePoint Document Library, or on a custom ASP.NET page in MOSS using the <XmlFormView /> control.

[Gotcha: the Document Library containing the browser-enabled form and your custom ASP.NET page have to live within the same Site Collection! Here is a great article on the MSDN site detailing the steps to use the XmlFormView control.]

Popular Misconception #2 - “I can publish an InfoPath form as browser-enabled, and it will look and feel just like InfoPath Client.”

Well, no. It’s good, but it’s not *that* good. The rendering is pretty faithful, but there are some features that are just incompatible. There are others features that behave quite differently in the browser-enabled version.

The images below show how the a simple for can render in both a browser and the Office Client, left and right respectively.

InfoPath Form in a Browser - Click to zoom!InfoPath Form in a Office Client - Click to zoom!

Some field types available in the Office Client just aren’t available in (this release) of the browser-enabled forms. For instance, instead of Combo Box fields, you have to use List Box fields. Instead of Rich Text fields, you have to use multi-line text boxes. It can’t be long before this gap is closed. With the current crop of AJAX frameworks (Microsoft, ExtJS, others) these controls should be able to be represented. Maybe next version.

There are other differences too: browser-enabled forms with complex logic, multiple data sources, business logic events and a raft of other conditions can cause your form to require a postback during editing. This is all handled automatically, but it can still cause a downgraded user experience, and increased server load.

[Gotcha: You can’t publish InfoPath 2003 forms as a browser-enabled, Office Forms Server form! InfoPath 2003 uses a COM APIs, whereas InfoPath 2007 and Office Forms Server 2007 use .NET APIs.]

Xsn file opened as a Cab - Click to zoom!Popular Misconception #3 - “InfoPath forms are just Xml. I can create them in Notepad if I wanted to.”

“Close,” as Roy Walker would say, “but not right.” The principle is that InfoPath forms are defined as Xml. When you create one and save it, you get an .xsn file. As with much in the world of WSS and MOSS, these files are re-purposed and re-named .cab files. Here’s something you can do: create a simple InfoPath form, save it as an .xsn file and rename it – changing the extension to .cab.

When you double click it, Windows Explorer should open up the .cab and show you the contents.

Typically, an .xsn file you create will contain by default a few different Xml files:

File Type Purpose
manifest.xsf The core InfoPath form definition file. Defines the fields, repeating blocks and controls used in your form.
myschema.xsd Xml Schema Definition file that defines the shape of your Xml data. In the case of InfoPath forms that consume web services, this is generated from the WSDL.
sampledata.xml Specifies what the default values should be for each of the fields on your form.
template.xml The Xml document that InfoPath will populate with data and submit.
view1.xsl An Xslt file describing how to render the form. Incidentally, forms are rendered, even in the InfoPath Client, as Html.

It will also contain any media files that you embed in your form, such as images and logos, and any further view*.xsl files specifying additional views on your form. If you have .NET business logic in your form, the resulting .NET assemblies will also be included in the archive.

Popular Misconception #4 - “I can only create InfoPath forms in the designer of Office InfoPath Client.”

Visual Studio Tools for Office 2005 and Visual Studio 2008 form a great environment for developing InfoPath forms. This gives us two choices:

  • A combination of InfoPath Client 2007 designer to design the form and Visual Studio Tools for Applications (VSTA) to create .NET business logic
  • Visual Studio 2005/8 with Visual Studio Tools for
    Office (VSTO)

The picture below shows the a similar form being designed in both environments.

InfoPath Forms development environments - Click to zoom!

There are pros and cons with each method.

  • Visual Studio 2005/8 requires a license! If you aren’t developing other .NET projects, VSTA and InfoPath Client provide a robust and flexible development experience.
  • Visual Studio 2005/8 with VSTO uses its own rendering engine in the designer – there are some discrepancies between what gets rendered in each. The InfoPath Client offers the more faithful reproduction during design.
  • The premium development environment is still Visual Studio 2005/8. VSTO and Visual Studio integration is very close indeed. With InfoPath Client and VSTA you are using two separate applications.

For the hardened developer, Visual Studio 2005/8 will be the better of the two choices.

Here you can read Microsoft’s Andy Whitechapel discussing the differences between VSTA and VSTO.

Happy coding!

Technorati Tags: InfoPath, Microsoft, MOSS, SharePoint Architecture, VSTA, VSTO, XSN

I don’t know if there’s enough of these to make a series, but I’m going to give it a go.

I’m going to start with a MOSS Excel Services tip. If you’re already using this in anger, then I’m preaching to the converted. If you’re considering using Excel Services, or you’re about to advise a client on Excel Services, there’s a few things you need to know.

First off, some stuff you’ll probably know. Excel Services is a great platform for consolidating spreadsheets and bringing order for clients that are heavy Excel users. Investment banks – we know who you are – you folks with tens or hundreds of thousands of complex spreadsheets that get emailed about between users. Some of these spreadsheets are used to make multi-billion dollar decisions for the larger banks. Often, the authors of these spreadsheets are long since departed. Frequently, the banks daren’t make material changes to the business logic therein, just in case it all goes a bit Pete Tong.

Similar stories exist even when there aren’t decisions being made with quite such a high dollar-value. Government departments, pharmaceutical companies, accountancy firms, consultancies – the list goes on. All places with the potential to generate tonnes (can I measure digital data by weight?) of spreadsheets copied from user to user.

Microsoft Office SharePoint Server provides check-in and check-out to help restrict this kind of proliferation, as you’d expect in common with the rest of the Document Library features of MOSS. Excel Services gives us much more on top of that

When you add an Excel spreadsheet to a suitably configured Document Library, you can use Excel Web Access – kind of like Outlook Web Access - to view and interact with it. In fact, viewing through Excel Web Access is the default action on Excel spreadsheets in such a Document Library. There is also programmatic and web service access to Excel Services, which I’ll try and come to in another blogging.

Which brings us to:

Popular Misconception #1 – “You can edit the spreadsheet through the browser. The spreadsheet experience is just like the real thing – just like Google Docs.”

Nope. No you can’t. No it’s not. Sorry.

It’s good though! And what it offers is valuable. Instead, you get 60-70% of the core Excel desktop experience through the browser. Graphs, colour bars, pivot tables. All good, all decently rendered. And you can interact with the sheet through settable parameters and filters.

You can’t edit the sheet and you can’t save it. If you want to do that, you can either open the sheet in Excel client on the desktop, or create a “snapshot” – once again, for use in Excel client.

Why is this good? If you expose the sheet *solely* through Excel Web Access, none of your hard earned intellectual property – none of your business logic – ends up in the hands of your audience. You can build dashboards in MOSS that show regions of multiple spreadsheets or charts side-by-side with Key Performance Indicators (KPIs) or any other information you want to display.

Popular Misconception #2 – “I can take one of our complex spreadsheets and just stick it in Excel Services and have it run server side.”

Nope. Sorry. You’ve more than likely got some work to do. If your spreadsheet uses:

  • VBA macros
  • COM add-ins
  • User Defined Functions

…you have some difficult decisions ahead of you.

If a lot of your business logic resides in VBA macros, you’ll need to consider recoding these as an Excel Services User Defined Function (UDF) in a .NET language. If your spreadsheet does lots of gnarly Monte Carlo analysis using a visual COM add-in, once again you’re left with a significant coding exercise.

If you’re lucky enough that your spreadsheet already uses client-side, C language User Defined Functions, you can either, once again, re-code them as an Excel Services Managed UDF – or write a managed wrapper for them.

There is a good list of unsupported and partially supported Excel client features in Excel Services here.

So, how do you do it? It can’t be easy, surely?

Popular Misconception #3 – “SharePoint Excel Services UDFs are difficult. It’s better just stick to simple spreadsheets and keep the complex ones as desktop spreadsheets.”

Very, very easy.

First, create a .NET 2.0/3.5 managed Class Library project in Visual Studio 2005/8.

Second, make a reference to Microsoft.Office.Excel.Server.UDF.dll, which is usually sitting here: C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\ISAPI on a server with MOSS installed.

Third, we’ll write our class and methods. Here’s a C# example.

   1: using System;
   2: using Microsoft.Office.Excel.Server.Udf;
   3:
   4: [UdfClass]
   5: public class MyUDFClass
   6: {
   7:     [Udfmethod]
   8: public double MyUDFMethod(double x, double y)
   9:     {
  10: return x * y + y;
  11:     }
  12: }
We tell the UDF framework that our class contains UDFs by decorating it with the UdfClass attribute – in line 4. Similarly, you mark up one or more methods as being a UDF by decorating then with the UdfMethod attribute – in line 7. You can read an in depth tutorial on msdn.com here.

That’s more or less it. You’re now at liberty to fill your class and methods with as complex business logic as you see fit. The final step is configuration of the Shared Service Provider (SSP) for Excel Services, and deployment to a MOSS server – which may well be the topic of a future blogging.

To use your new UDF in a spreadsheet couldn’t be easier. You don’t even need to deploy the UDF to the desktop machine you’ll use to create the spreadsheet. Simply open a new spreadsheet, and use your function in a formula as if it meant something to Excel, thus:

Using a Managed UDF in Excel Client
Figure 1 – Using a Managed UDF in Excel Client

Yes, when you hit return it will get resolved to “#NAME?” as if it doesn’t recognise it. This is, of course, because it really doesn’t recognise it, and it won’t be recognised until you deploy that spreadsheet to a correctly configured Document Library.

That’s it for this time! :)

If you’ve been evangelising Excel Services having never used it, I hope this has cleared up a couple of common misconceptions. If you’ve been tempted to, but never quite made the jump, I hope this has given you a push to just *try* Excel Services. They’re pretty cool and, as I hope you’ll see, offer a compelling business story for bringing Excel spreadsheets back under control.

Technorati Tags: Excel Services, Excel Web Access, MOSS, SharePoint, UDF, User Defined Function, WSS