I’ve known for quite a while that SMIGRATE backups (FPB)s were simply renamed CAB files. Today I had a collegue show me that STP files are just renamed cab files too. When you create a template — either for a list or a site the resulting STP file is just a renamed cab file with a manifest.xml file. I’m not sure what I’m going to do with this new found knowlege but it is definitely cool. (It might make it possible to apply a template to a different site definition for instance.)
I blogged earlier about using the XmlNamespaceManager to get back nodes from SharePoint XML fragments. I found a better way (with the help of some BizTalk MVPs that I got to hang out with recently). Instead of doing /wp:Fields/wp:Field or whatever nonsense that you need to do to get the XmlNamespaceManager to work use the local-name() function so … /*[local-name() = ‘Fields’]/*[local-name()=’Field’]
I’m sure someone will tell me why that isn’t very performant … but I don’t care it works, it’s clear to read, and I don’t have to go through hoops to get the XmlNamespaceManager hooked up.
This isn’t the article that I set out to write. While researching another article (coming soon) I soon realized there just isn’t a lot of good material on how to troubleshoot Web part deployment, or even precisely how Web part deployment via STSADM even works. This article is designed to explain the moving parts of the deployment process and describe what can go wrong. Hopefully, it will help a few people get their implementations up and running more smoothly.
Why Deploy with STSADM?
Before getting too deeply involved in fixing STSADM Web part deployments, it’s important to understand what STSADM is and why it’s a good platform for troubleshooting Web part deployment.
STSADM is a ‘utility knife’ type of tool that ships as a part of Windows SharePoint Services. It does a wide range of things from site creation to Web part pack installation. If you have SharePoint Services, you already have this utility; it is typically found in C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\60\Bin.
Maurice Prather’s original post on AppDomains to get around some issues with impersonation and the object model was great. It was an approach that works to allow most applications to do what they need within the SharePoint world — even if SharePoint doesn’t allow the user to directly perform the action. His update fills in some small holes in the original article — including one or two that I must admit I fell into. Maurice was kind enough to help track down the issue (the second call to impersonate that I wasn’t doing but he was) and get things straightened out. My problem was the one exposed by Mike Donovan on IRuntimefilter getting roles for a user.He worked around it with a web service call, but that’s not an option in my environment since performance will definitely be an issue.
I can also say that a SharePoint architect that I placed with another client has used the AppDomain technique to get by a wide variety of issues. So in short, if you need to do impersonation, this is the way to do it…
Before buying a tool, make sure that you understand the problem, all of the alternative solutions to the problem, what else you’ll need to implement the solution, and whether it’s a problem you should even try to solve on your own. Developing a routine before buying tools will help to prevent purchasing tools that you’ll never use.
My father is a tool guy. He has more tools than any sane person should have. I learned that there are a dozen different saws—each for a different purpose. I’ve inherited this love for tools, although I get more crazy about gadgets than power tools. I realize that I’m not alone. Often times I recognize an automatic instinct in clients towards buying a software package to solve a problem — and occasionally even a hardware purchase. Unfortunately, the tool—whatever it is—is just a tool. It can’t solve the problem by itself. It needs to be wrapped in a solution to solve any problem. Here are five questions to ask before you buy a tool to try to solve a problem.
Do you understand the problem?
Most of the time IT professionals are so pressed for time that they don’t make sure that they fully understand a problem before they try to solve it. We talk about requirements for big projects but we often forget that the same principles apply to smaller purchases.
For instance, a recent client was confronted with a group that needed Act!. Of course, that was a solution, not the problem. The problem was a basic contact management problem. They needed to keep basic details of contacts for a group of people. The client already had Exchange — but ended up purchasing Act! because the requirements weren’t understood. The group that Act! was purchased for is slowly moving back to an Outlook and Exchange public folder solution. (To be clear, there are some problems for which Act! is the right solution — it just wasn’t a good fit for this organization.)
No matter the size of your organization, you can be sure you have old software sitting on a shelf somewhere. Robert Bogue talks about how to reduce the shelfware in your company.
Every organization has “shelfware” (software that has been put on a shelf). Whether an organization has 100,000 people or only one person, you can be sure there’s software sitting on a shelf somewhere in the building. In some ways, shelfware is like cholesterol. There’s a good kind of shelfware and a bad kind of shelfware. The trick is to increase the good shelfware and reduce the bad shelfware.
How does shelfware become shelfware?
There are actually a few different kinds of shelfware, some shelfware was never used or never returned the value that was intended. Other shelfware was retired to its position only after it had performed its service and was no longer needed.
For example, I once licensed a program called LinkBot Pro from Watchfire that validates web references. This tool was invaluable in helping me validate links in older versions of Que Publishing’s Official Internet Yellow Pages. I bought the license, used it for the project, and then it became shelfware. This is a good form of shelfware —software that more than provids its value and is then peacefully put out to pasture.
There has been a fair amount of talk lately about how any web part page in SharePoint — including many pages like list pages that people don’t think are web part pages — can have the web parts manipulated by simply adding parameters to the query string. Those parameters cause the ToolPartPane to appear even if there was no administrative control on the page to cause it to appear.
This is true of the existing pages, but you can create your own site definition that doesn’t allow users to use the user interface to modify the web part placement or even add new items to the web part zone. The WebPartZone class (and consequently the WebPartZone tag) support three interesting attributes/properties…
- AllowCustomization – Indicates whether customization is allowed or not.
- AllowPersonalization – Indicates whether personalization is allowed or not
- LockLayout – Indicates whether the layout of the zone is fixed — and can not be edited.
Quick testing shows that AllowCustomization must be set to true and LockLayout must be set to false for SharePoint to even show the web part zone in design mode. Further investigation has shown that using the web services calls to modify web parts in the web part zone still seems to work — and editing the page in front page including web part placement still seems to work as well. In other words, it’s possible to prevent users from modifying web parts in special zones, like navigation, while retaining the ability to control web parts in these special zones via code.
I was searching out some things and ran across an old blog entry from Bil Simser talking about the limitations of using folders because of path length limitations. Here are a few observations from a recent client experience.
1) The path limitation is indeed 255 (or 256 characters). It’s documented in some of the planning documents (and in a KB article as well if memory serves.)
2) The idea of using meta data to categorize information instead of folders has at least two limitations …
a) WebDAV doesn’t natively support the assignment of meta-data during a save operation. Therefore saving with applications which are not fully SharePoint aware is a bad experience. The documents end up in the “root” of the view since they have no data to categorize them.
b) Retreiving files without context from a SharePoint document library can be very difficult without the property information. Since the WebDAV File-Open dialog doesn’t understand the meta data it can be frustrating to find the right document to email to someone when the file name doesn’t contain all of the useful information. One solution around this particular problem is to use the free Outlook Power Tool for SharePoint from Winapp Technology. Of course, that doesn’t solve the problem when you’re trying to use a file from another application.
In general… Use meta data if you need the ability to reorganize the data in multiple hierarchies. Use folders to make it easy to use within non-SharePoint enabled applications.
As a sidebar, the experience on SharePoint with WebDAV is much better in Windows XP vs. Windows 2000. Every application I’ve tested has been able to save to SharePoint via WebDAV in Windows XP. The same applications have trouble with Windows 2000’s support for WebDAV. XP also allows files to be dragged from one WebDAV folder to another where Windows 2000 does not.
For those of you who have been asking … I’m not going to the PDC. I had a decision to make — admittedly a tough one. The MVP Summit is at the end of the month. I don’t have enough slack in my schedule to do two events in one month. So, as much as I wanted to hear about SharePoint V3 as soon as possible … I had to decide to go to the Redmond campus at the end of the month. It gives me a lot more opportunities to talk with the program managers — in a slightly more intimate setting.
So, keep the blog entries about the PDC coming, I’ll be reading them intently.