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 ‘WSS’

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

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

Freelance SharePoint Consultant and Trainer

sharepoint-logoI’ve been busy of late, reinventing myself a bit.

If you search for Microsoft Technical Due Diligence on Google, I’m there at link #5. Which is quite cool.

But if you search for SharePoint consultant or trainer, I’m nowhere as far as Google goes. So I’ve got to do something about that.

I’m always interested in SharePoint solution architecture, development and consulting roles. I can also offer on site, bespoke training for SME and corporate customers looking to cross-train their development teams to Microsoft Office SharePoint Server 2007 – MOSS -  and Windows SharePoint Services 3.0 – WSS.

If you’re interested in bespoke SharePoint training or consultancy coming to you, check out my details here: http://www.jfdiphoenix.co.uk/sharepoint+training.aspx

Technorati Tags: MOSS, SharePoint, Training, WSS