Time for a little self promotion here I think! I’m pretty proud to announce that my company, Second Foundation Intelligence, (in case you haven’t noticed the logo on the upper right of this page…) has been named a finalist for Business Intelligence Solution of the year at the upcoming Microsoft Canada Impact Awards ceremony.
We’re pretty excited and pretty proud of it. For the solution in question, we’ve built out an end to end budgeting system using SharePoint Server 2010, SQL Server 2008 R2, and Excel 2010 for a local municipality. Here is a link to the press release.
We’ll see it early next year, but we already have a pretty good idea of what will be there. All of the constituent products (SharePoint, Exchange, LiveMeeting and Office Communication Server, now Lync) will be brought up to their most recent versions, and the Office Web Applications will be added in. In light of the changes, and the expected change in focus to the Office Web Apps, the new name makes a lot of sense. I’m just glad that I don’t have to call it BPOS anymore…
First off, I should state that there’s really no such thing as a site collection template. What happens when a new site collection is created is that the collection gets created, and then a web template is applied to the root site. This whole process is actually decoupled in SharePoint 2010, and you no longer need to select a template when the site collection is created (as documented previously by Todd Klindt). Todd has a very clever solution to getting your web template to be used at the root site, but I recently had a requirement to have it fully automated, and to be visible to the templates available when creating a site collection in Central admin.
This was relatively straightforward in SharePoint 2007, you would save a particular site as a template, then go to the template gallery, download it to the file system on a front end server, and then run an STSADM command to have it added to the Site definitions list. However, in SharePoint 2010, site templates are no longer .STP files,they use .WSP solutions in the user solution gallery. That should be easy,right? Just save off the WSP file, add the solution to the farm with either PowerShell or STSADM. The solution will actually install, but your site template won’t show up. The main reason is that the actual web template is scoped to “web” and for it to show up for site collections, it needs to be scoped for the farm.
The good news is that you can import a WSP file directly into Visual Studio 2010, edit it, and create a new solution that does work. I will now attempt to describe the relevant steps, and a few gotchas to do this.
1. Save The Site as a Template
Once you have your site looking and behaving the way that you want, it’s time to save it off. Select Site Settings, and click Save Site As Template – It’s under the Site Actions section. Give the template a file name, name, and if desired, a description. Once you select OK, the solution will be created and saved to the solution gallery, which is at the root of the site collection. You’ll want to go there next, and you can do so by clicking on the “solution gallery” link in the successful save confirmation page, or by navigating to the root of the site collection, then selecting Site Actions – Site Settings and clicking on the Solutions Gallery link. There is no more Site Template Gallery!!!
2. Save the WSP File Locally
From the solutions gallery, Click the name of your solution, and you will be prompted to save the wsp file. Go ahead and do that, and then you need to delete the template from the gallery. Why? You’ll be ultimately registering it in the farm, and you don’t need any confusion as to which template to choose. As well, if you’ll be using the same name, this will lead to conflicts, so it’s best to eliminate it altogether.
3. Create a Project in Visual Studio
Open Visual Studio and create a new project. Make sure that you have the SharePoint 2010 Templates showing, and then select the “Import SharePoint Solution Package” template.
From the next screen select “Deploy As a Farm Solution”, and click Next.
Next, click Browse and navigate to the WSP file downloaded in 2.
Finally, ensure that all of the included items are selected, and select Finish.
Visual Studio will then import all of the items into the project. Now we’re ready to modify the project.
4. Modify The Feature Definitions
There will typically be 4 Features created for a site template, aptly named Feature1 through Feature 4. Personally, I like my feature names to be a little more descriptive than that. Feature 1 is for List Instances, Feature 2 is for Modules, Feature 3 is for the template itself, and Feature 4 is for the PropertyBag.
The purpose of our solution is to make the site template available, and the other features are effectively there in a supporting role. Currently, all 4 features are scoped to web, and all 4 are visible. In addition to renaming them, we want to hide features 1,2, and 4 from display, and we want to scope feature 3 to the farm.
First, we’ll modify the Feature name. Simply Single Click (or right click and rename) on the Feature in the Visual Studio Solution Explorer, and enter a new name. You’ll notice that all of the supporting elements below are automatically renamed as well.
Next, We’ll want to modify the Title of the features. The title is what is used when the feature is displayed in the feature list. Although we’ll be hiding 3 of them, it’s still a good idea to use a descriptive title. Double click on the feature, and the Feature Definition box will open in the main window. Modify the Title, and if desired the Description field to something meaningful to your users.
Go ahead and repeat this step for all of the 4 features
With the feature definition in the main window, the feature properties should be loaded in the properties toolbox (if you don’t have it open, open it). We want to set the Is Hidden property to true for all of the features except for the Web Template feature itself (Feature 3).
The web template feature itself requires an additional modification, we need to change the scope from site to farm. We can do this in either the properties window or the feature definition window, but the feature definition window is a little more obvious.
5. Modify the Template Definition Itself.
This step may not be required if the template name and title will be identical to that which was saved initially. However, in this case, we have called the solution Sample 1, and when the template was saved, it was MyCustomSite. We need to modify the template itself to be called Sample 1, and we may have some additional tweaks.
From the Solution Explorer, open the Web Templates Folder and change the name of the Template by single, or right clicking on it. The feature definitions will be updated automatically.
Next, we need to open the Elements.xml file, and change the Name and the Title tag to the new name. Search and replace is a good idea here. Next, open the ONet.xml and change the Title attribute in the Project tag to an appropriate value, in this case, Sample 1. This file can also be used to remove any feature dependencies that may not exist in the destination farm, but be careful – other elements of your template may be reliant on them.
6. Test the Project
Click on the Debug start button in Visual Studio and your template will be deployed to the server, and you’ll be prompted to create a new subsite. If you see your template in the custom tab, all is well. Go ahead and create a test site to make sure that everything is working. Visual studio may prompt you with deployment conflicts, just let it go ahead and resolve them automatically.
7. Deploy the Solution
We are now ready to deploy the solution to the farm. First, set Visual Studio to Release mode from the toolbar:
Then, Right Click on the project, and select Package
Then, you’ll need to navigate to your Visual Studio project folder, and then into the BINRelease folder. There you will find a .WSP file with the name of your project. You can either work with the file in place, or copy it to a folder, but next we will add the project to the Farm solution gallery. To do this, we will either use STSADM (old school) or PowerShell (the cool new way). I’m old, so I still use STSADM for solutions, but I’ll show both.
To add the solution using stsadm.exe, open up a command prompt (in administrator mode if UAC is turned on), and navigate to the folder containing the solution file. The syntax is:
C:Program FilesCommon FilesMicrosoft SharedWeb Server Extensions14BINstsadm.exe –o addsolution –filename sample1.wsp
Where sample1.wsp is the name of your solution file.
To use PowerShell, open the SharePoint 2010 Management Shell, and enter:
The argument for LiteralPath is the complete path to the solution file. If there are and spaces in the path name, it needs to be encased in quotes.
8. Deploy the Solution
Now that the solution has been added, it needs to be deployed. To do so, start central admin, Go to System Settings, and select Manage farm solutions in the Farm Management Section:
Click on your solution name, and then click the Deploy Solution button. Click the OK button on the following screen, and your solution will be deployed.
You can control whether or not the template is available by turning off the farm feature. You can do that from central admin by navigating to System Settings – Manage Farm Features. From here, you can turn your template on and off.
9. Create New Site Collection
At this point, we should be good to go. From Central Administration, navigate to Application Management, and click Create Site Collections. On the create screen, give the new collection a title, and a URL. Then, in the Template Selection, click the Custom tab, and your template should appear there.
Give it a site collection administrator, and click OK. After a few moments, the site will be created, and you can navigate to it.
Well, Microsoft giveth and Microsoft taketh away. Adding the template to the farm is considerably more involved with 2010 than with 2007. However this approach is also a great deal more flexible – you can tweak that template to your heart’s content, and if you have ever tried to create a site template with 2007 using Visual Studio, you can really appreciate how Visual Studio 2010 makes it significantly easier.
A few weeks ago I posted an article on how to get on premises SharePoint working with BPOS for mail delivery (alerts, etc.). Historically, inbound email is something that is significantly trickier than outbound, but with hosted Exchange, I’d suggest that the two roles are switched in terms of difficulty. There are however still a couple of extra hoops that have to be jumped through, and I’ll try to guide you through them here.
For the purposes of this article, I’m going to assume that you’ve already done this when you set up outgoing mail. If not, I’ll refer you to my article linked above, or SharePoint George that will walk you through the requisite steps. Once it’s done for outgoing email, you don’t need to touch it for incoming.
2. Configure the SharePoint Farm to Accept Incoming email
First,you’ll need to navigate to Central Administration,and get into the System Settings section. Once there, select “Configure incoming e-mail settings” in the E-Mail and Text Messages section.
There are a number of settings here that will change a bit from what is the typical guidance out there. I’ll try to explain each configuration item, and what it means. Firstly, I’ll show you a completed configuration:
Enable Incoming E-Mail – Well, that’s pretty straightforward, do I turn on incoming email or not? When you turn it on, SharePoint simply monitors an SMTP drop folder for any messages. If it sees one, it will pick it up, and if the destination name matches a list, it will get delivered. It’s really that simple.
The settings mode lets you choose where the drop folder is. The Automatic setting is normally fine, but if you wanted to use a drop folder in a non default location, or on another server, you would select advanced and enter the desired folder. When the configuration is saved, SharePoint will also try to set the appropriate file system rights on that folder (see George’s blog for more details). I set advanced just so I see the path explicitly.
Directory Management Service – This one normally takes a fair bit of configuration to get working, but when we’re using BPOS, it’s easy – we just set it to no. This is a service that sets up contacts and distribution groups in Exchange, and although we’re using Exchange, it’s hosted, and don’t have access to that feature. We will be creating these manually.
Incoming E-Mail Server Display Address – This is the domain that the list email addresses will use. We’re going to change this. It will default to servername.domain.com. However, even if that address is available externally, we don’t want to be accepting mail from everyone. The IIS SMTP service has no real spam or virus protection, so we want all of our email to go through our hosted Exchange server. The best approach is to use the same domain as your other BPOS users.
E-Mail Drop Folder – As mentioned above, this is the folder that will be monitored for incoming email. If you don’t know if you should change this, then don’t… the default is likely fine.
Once you’re done, click OK to save the configuration. SharePoint is now set up to configure incoming email. Steps 3 and 4 will need to be repeated for every list/library that will accept email.
3. Configure Library to Accept Incoming E-Mail
Navigate to a library that you want to have accept incoming email. From the ribbon, select “Library” (or List..), and then select Library Settings.
Next, under the Communications Column, click the “Incoming e-mail settings” link. You should see a screen similar to the following:
Most of the options are self explanatory, so I won’t go into detail here. The most important ones are of course in the Incoming E-Mail section, which lets you turn it on or off, and lets you specify the address of the list. The address is important, as it will need to match what we do in BPOS in step 4, and it is also important that it is global across the farm (and of course the domain). That name can’t be repeated, so choose wisely. A naming policy is a good idea here.
Once you have the settings the way you want them, click OK, and your list is ready to go. Now it’s on to BPOS.
4. Configure the Address in BPOS
This is where it gets interesting. What we want to do is to have BPOS accept email from internal (and possibly external) senders, and then turn around and deliver them to out IIS SMTP service. Usually, we could set up a contact in Exchange and use mail forwarding to do this for us, but there is no mail forwarding capability in BPOS. So how do we accomplish this? Instead of using mail forwarding, we’ll set up a distribution list with one member, and let it work its magic that way.
The first thing that we need to do is to log into the admin portal at http://admin.microsoftonline.com. Once in click on the Service Settings tab, and then click on the Exchange Online subtab. From the right hand Actions section, click the “Add new contact” link. You then need to add your contact, which in effect is the library that we enabled in 3 previously:
Most of the fields are cosmetic (they will appear in the GAL), but the most important one for our purposes is the E-Mail address. note that this address is NOT the same as the one that we configured for the list, but includes the server name as well. This is important as BPOS needs to deliver the mail to that server. It is also important that that server address is available to BPOS (on a public DNS). This represents one half of the equation. In the next step, we’ll configure BPOS to accept the email for the list’s address by using a distribution list.
Once ready, Save your changes, and then click on the Distribution Lists link on the left of the screen. From the Actions section on the right, click “New distribution list”.
The Email Alias used here must match the one used in 3 above, and. The display name is relatively unimportant, but again will be available to the GAL. Once you save this screen, you should be ready to go.
It’s worthwhile to describe the flow of what happens. When an email is sent from a user, external or internal, the originating server will look for an MX record for the address to the right of the @ symbol. That MX record will point to your BPOS server. The BPOS server will accept the name, as it matches the distribution list that you created in step 4. The message will then be distributed to the members of the list, in this case one member at the precise SMTP address of the server farm. BPOS will send the message to the SMTP server running on the farm, where it will be deposited to the drop folder. Finally, the timer process in SharePoint will pick up the message and deposit it into the appropriate library.
In a previous article, I wrote about the fact that with Microsoft SharePoint 2010, the default behaviour for handling PDF files is to prompt for download instead of opening them directly in the browser. In it, I mentioned how to change this behaviour, both at the application level, and where necessary at the library level.
I recently ran into a case where neither approach fixed the problem. SharePoint continued to prompt for download even though the BrowserFileHandling property was set to permissive at both the application and at the library level. I registered a support call with Microsoft and was told that they’ve seen this, and were working on it, and there was no expected date for an answer.
I decided to do some further experimenting, and found that I was actually running into two different things that caused this. The environment had both, so it made troubleshooting a real treat.
1. Adding the PDF icon to the front end server causes prompting for download
It’s been standard procedure since SharePoint 2007 to manually add in the PDF icon to display PDF documents, as described here. Every time that I do so, SharePoint starts prompting for download instead of opening in the browser. I as yet have no idea why,but it’s repeatable. UPDATE – This has been solved – see below.
2. Creating a site from a custom site template causes prompting for download
With the PDF icon uninstalled,the browser behaviour is correct on all sites in the site collection. If you then create a site template from an existing site with a library, and then use that template to create a new site, you will experience the prompting behaviour on any documents saved to that library. This is NOT true for any new libraries created in the site. You can also run the PowerShell script that I previously posted to reset the properties of the libraries, and they will behave properly.
For the record, the environment that I was working on this problem with was Search Server Express 2010, which is essentially the same as SharePoint Foundation plus the Search features from SharePoint Server.
Both of these problems are quite annoying, and I suspect I’ll be updating this post as I learn more, or as I hear back from Microsoft.
I’ve put together a solution that can be installed on a farm and activated at the site collection level. It’s essentially an event receiver that fires whenever a new web (subsite) is created and it sets all of the lists to Permissive. It works fine for me, and for at least one customer, and I provide it to you here with no warranties express or implied…. If anyone is interested in the code, let me know, but it’s only about 5 lines.
UPDATE – OCT 15 2010
The pdf icon problem has been solved. I’ve been back and forth with Microsoft on this and we wound up exchanging DOCICON.XML files. They sent me back one that worked, and the suggestion was that I change the icon file name to pdf16.gif to accommodate it. However, I noticed that there was an additional attribute in their file, OpenControl=””. I added that to the Mapping tag for my PDF extension, did an IISReset, and the problem was solved. For the record, the complete tag will look like:
With pdf16.gif being whatever the name of your pdf icon file is.
Microsoft also confirmed the problem with the custom site templates that I created the solution for above. It’ll have to do until a fix is available.
UPDATE – JAN 3 2011
Reader Christoffer von Sabsay has notified me that this bug has been fixed in the December 2010 Cumulative Update Pack for SharePoint Foundation. For a list of the fixes in this CU, and to request them, go to http://support.microsoft.com/kb/2459108. My event receiver workaround should NOT be required after applying this and you should remove it upon doing so.