If you’re building custom application pages within MOSS and need some guidance on how to build your pages using Telerik controls, I’ve outlined some steps to get you started.
- Create a new folder within the
1
c:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\LAYOUTS
directory to store your custom application pages. For example:
1
c:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\LAYOUTS\CustomPages
- Create a new aspx page and use the attached code as a starting point. Let’s name it Demo.aspx. The trick to creating this page was to use the td styles defined by SharePoint to accomplish the same look and feel as the rest of the layouts pages within the application. We will see how this works in the next few steps. The attached zip folder contains two files: Demo.aspx and DemoFinal.aspx. The only difference between these two files is that DemoFinal.aspx contains assembly registrations for the telerik controls, and replaces the standard asp:TextBox control with the Telerik RadDatePicker control.
- In order to add breadcrumbs to your new custom application page, you’ll have to add an entry to the layouts.sitemap file located in the inetpub folder
1
C:\Inetpub\wwwroot\wss\VirtualDirectories\80\_app_bin
as outlined in Jan’s blog
1
<siteMapNode title="Demo" url="/_layouts/snc/Demo.aspx"/> - The next step is to add a safe control entry for the rad calendar control. One thing to note is that the radcalendar control also utilizes the radinput control, but we only need to add radcalendar.net2.dll as a safe control entry even though both will reside in the gac.
1
<SafeControl Assembly="RadCalendar.Net2, Version=2.2.1.0, Culture=neutral, PublicKeyToken=a1432cd341173140" Namespace="Telerik.WebControls" TypeName="*" Safe="True" /> - Install radcalendar.net2.dll to the gac
- Install radinput.net2.dll to the gac
- If you plan on skinning your control, you have to add the RadControls\Calendar\Skins to the web app root. An example of the web app root would be
1
c:\Inetpub\wwwroot\wss\VirtualDirectories\80.
In order to track this down, within IIS manager, right click on the web site properties and click on Home Directory. That should tell you where your website root is located. Copy the files to this location.
The hierarchy should look similar to the screenshot below:
- You can now apply the skin in your control by editing the skin property as follows:
- You can review what your final version should look like by comparing it to the file attached to this post.
Sometimes, when I attempt to remove a form template that was deployed as an administrator approved template, I run into issues. If you’ve ever received the error below, then you’ll have to use stsadm to remove the feature that is associated with that particular form template.
This form template was deployed as part of the FT-01-f97dd99b-7ea7-1c56-25e5-eddf7ff6099b feature. This form template should be removed only by uninstalling that feature.
Resolution:
stsadm -o uninstallfeature -id idoffeature -force stsadm -o uninstallfeature -id f97dd99b-7ea7-1c56-25e5-eddf7ff6099 -force
To determine the id, navigate to the
C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\FEATURES\FT-01-f97dd99b-7ea7-1c56-25e5-eddf7ff6099b
and locate the feature.xml file. The id will be located inside of this file.
The InfoPath team blog has a great post on becoming a better template administrator:
Behind the Scenes of Administrator-Approved Form Templates
If you’re working with custom workflows, and you’ve run into a scenario where you have the login name of the user in the form of domain\juser but would like to see a more user friendly display name like Joe User then here’s how you do it:
What I usually do is create an SPUser object and then use the Name property to get at the display name of the user. Once I’ve got an SPUser object created, I have access to several different properties and methods. You can view the full list on msdn. The SiteUsers property will take in a string containing the login name of the user
SPUser user = workflowProperties.web.SiteUsers[string loginName]; string fullName = user.Name;
The scenarios I’ll talk about in this post will describe some of the issues I recently ran into while trying to do a content migration from one server to another. I’ve outlined each scenario that was tested, the errors I ran into, and what resolutions I was able to come up with.
Please note that in all of the scenarios below, I am working with two separate servers, both running on a different server farm, but within the same domain.
Scenario 1
- A web application and a site collection already exist on the source server based on the Collaboration Portal template.
- You create a web application on server2 with a SINGLE site collection, based on the Team Site template.
- You configure a path from server2 to server1 and a job that will do a full content migration.
Result: Content migration will fail with an error similar to the one below:
Cannot import site. The exported site is based on template FOO but the destination site is based on the template FIN. You can only import sites based on the same template as the exported site.
Resolution: I will explain the reason for this error in Scenario 2. Please continue reading.
Scenario 2
- A web application and a site collection already exist on the source server based on the Collaboration Portal template.
- You create a web application on server2 with a SINGLE site collection, based on the Collaboration Portal template.
- You configure a path from server2 to server1 and a job that will do a full content migration.
Result: Content migration will fail just as in Scenario 1
Resolution: When migration from one site collection to another, the destination site collection must be based on the Blank Site template, otherwise, migration will fail.
Scenario 3
- A web application and a site collection already exist on the source server based on the Collaboration Portal template.
- You create a web application on server2 with a SINGLE site collection, based on the Blank Site template.
- You configure a Path from server2 to server1 and a job that will do a full content migration.
Result: Content migration should succeed. Again, when doing a migration from one site collection to another site collection on a different server, within a different web application, you’ll need to ensure that your destination site collection is based on the Blank Site template.
Scenario 4
- A web application and a site collection already exist on the source server based on the Collaboration Portal template.
- The destination web application is already created and contains A SINGLE site collection with the same content as the source site collection, either through a previous content deployment job that copied to that location, or via some other method like stsadm. We’ll refer to that as sitecol1
- You create a second site collection within the same web application on server2 based on the Blank Site template. We’ll refer to this one as sitecol2. You should now have 2 site collections within your destination web application: sitecol1 and sitecol2.
- Configure a Path from server2 to server1 and a job that will do a full content migration to sitecol2.
Result: Content migration will fail with an error similar to the one below:
Unable to import folder _catalogs/masterpage/Forms/Page Layout. There is already an object with the Id 62b662s-3344b-332bbs33-a334d-233k in the database from another site collection.
Resolution: Delete the extra site collection (so in this case, sitecol1) or move it to another web application. The error above is somehow related to having two different site collections within the same web application sharing the same content within the same content database, This seems to generate errors indicating that an item already exists.
Scenario 5
- A web application and a site collection already exist on the source server based on the Collaboration Portal template.
- The destination web application already contains a SINGLE site collection with the same content as our source site collection.
- You configure a Path from server2 to server1 and a Job that will do a full content migration. You may also create a new job that will only migrate changes. Either will produce the same results.
Result: Content migration will fail with an error similar to the one below:
The specified name is already in use. A list, survey, discussion board, or document library cannot have the same name as another list, survey, discussion board, or document library in this Web site.
Resolution: Delete the site collection from the web application. Create a new site collection based on the Blank Site template. Do a full content migration. Once that is successful, any new jobs that you create should be successful. The key thing to note here, is that you must begin with a Blank Site template. It’s not enough to have a site collection that contains the same content on the destination server, even though that’s what you essentially end up with after the first successful full deployment.
Once the migration has completed successfully, it’s important to hit a few pages within the site to ensure that branding/content is as it should be. If you do notice that the masterpage or stylesheets have not been set, then you’ll need to do that yourself.
I hope that helps anyone out there who was experiencing similar issues. Please drop me a note if you have any questions.
If you attempt to delete the default SSP from within Shared Services Administration, the Delete link will be greyed out. That’s because it’s the default SSP and SharePoint doesn’t allow you to delete the default SSP via the GUI.
One option to get around this is to create a new SSP and change associations to point to that new SSP. Once you do that, the Delete link for the original SSP becomes available because it no longer has any shared services associated with it.
If you’re like me however, and you don’t want to go to all that effort, then there’s a little trick to get around this.
stsadm -o deletessp -title SharedServices -force
The help for the deletessp command won’t actually indicate that -force is a valid switch, but without it, the command may fail. If you run into errors, try running it with -force.
The deletessp command will force the removal of the default SSP. If you receive an error after running the command, that’s fine. Sign back into Shared Services Administration and the delete link for the default SSP should no longer be greyed out.
Once you click Delete, you will be prompted to delete the associated databases, but in my experience, this generally doesn’t work. As a secondary step, I often find myself doing a bit of clean up. Within the database server, I remove all the default SSP databases and within IIS, I remove the SSP web site and application pool.
That should do it! You should now be able to create a new SSP. If you have any problems, or encounted an issue I did not cover here, please contact me or post a comment, I’d be happy to help.
You shouldn’t have to recreate your My Sites web app or any other web app that was associated with that SSP. You should be able to just re-configure those associations. Any search, profile or audience data will be lost and will have to be re-configured.
For anyone designing SharePoint Solution Packages (wsp files), typical deployment means either running stsadm commands to add a solution and then deploy it, or automating it via a script. However, if you’re building solutions that will be installed or administered by a client or a user not familiar with the stsadm command, then you’ll want to create something a little more user friendly.
That’s where MSI packaging can help. MSI packages also show up in add/remove programs and that makes it easier to manage for the end user. What i’ll outline in this blog post is some simple steps to get you going on creating MSI packages for sharepoint solutions files. To begin, i’ll assume you have already created a solution file and have it ready to go.
- Create a new Setup project: File -> New-> Project -> Other Project Types -> Setup and Deployment -> Setup Project
- Highlight the project and using the toolbar on the Solution explorer pane, select the User Interface Editor
- Configure the UI screens as you require
- On that same Solution Explorer pane, select the Custom Actions Editor and add the scripts below to the Install and Uninstall folders
- Using the File System Editor, add the wsp and license file to the Application Folder for use within the scripts below
- Building the solution will generate an msi file that you can now use to install your wsp. The msi will include all the necessary files, such as the license file, the wsp and the install scripts.
AddSolution.vbs
' VBScript File Set oShell = CreateObject("WScript.Shell") Dim activationUrl Dim targetDir Dim installDir targetUrl = Session.Property("CustomActionData") installDir = Session.Property("INSTALLDIR") Return = oShell.Run("cmd /C C:\Progra~1\Common~1\Micros~1\webser~1\12\BIN\stsadm -o addsolution -filename " + installDir + "\CurrentlyPublishedPage.wsp", 0, true) Return = oShell.Run("cmd /C C:\Progra~1\Common~1\Micros~1\webser~1\12\BIN\stsadm -o deploysolution -name CurrentlyPublishedPage.wsp -allcontenturls -immediate -allowGacDeployment", 0, true) Return = oShell.Run("cmd /C C:\Progra~1\Common~1\Micros~1\webser~1\12\BIN\stsadm -o execadmsvcjobs", 0, true) activationUrl = "cmd /C C:\Progra~1\Common~1\Micros~1\webser~1\12\BIN\stsadm -o activatefeature -filename CurrentlyPublishedPage\feature.xml -url " & targetUrl Return = oShell.Run(activationUrl, 0, true)
RetractSolution.vbs
' VBScript File Set oShell = CreateObject("WScript.Shell") Return = oShell.Run("cmd /C C:\Progra~1\Common~1\Micros~1\webser~1\12\BIN\stsadm -o retractsolution -name CurrentlyPublishedPage.wsp -allcontenturls -immediate", 0, true) Return = oShell.Run("cmd /C C:\Progra~1\Common~1\Micros~1\webser~1\12\BIN\stsadm -o execadmsvcjobs", 0, true) Return = oShell.Run("cmd /C C:\Progra~1\Common~1\Micros~1\webser~1\12\BIN\stsadm -o deletesolution -name CurrentlyPublishedPage.wsp", 0, true)
