Mark Arend : SharePoint

Debugging web parts and other SharePoint custom code

markarend — Tue, 09 Sep 2008 15:34:00 GMT

Here are some tips for debugging your SharePoint web parts and other custom code.

1. How do you debug assemblies that are in the GAC?

2. Is there an easy way of attaching the debugger to the right process?

Debugging assemblies that live in the GAC

When debugging an assembly that lives in the GAC, you have to copy the symbol file (.pdb) from your project to the GAC. The problem is, when you open a Windows file explorer to the GAC directory, C:\Windows\assembly, it doesn't behave like a folder that you can drag-and-drop into. You must copy using another method.

To view the GAC as typical folder structure using file explorer, enter %systemroot%\assembly\gac_msil in the Run... dialog box under the start menu. This folder opens the part of the GAC that contains managed code assemblies (from this location in file explorer, you can click the folder-up button to see other parts of the GAC).

From %systemroot%\assembly\gac_msil, locate the folder having the name of your assembly, and open that. Open the folder in there having the correct version number. Finally you’ll see the dll. To debug, drag the .pdb file from your bin\debug directory into that folder. You can also use an xcopy command to do this, now that you see the full path to the dll location. This path will change if you modify your assembly's version number. Note that whenever you upgrade your solution, the .pdb file is removed from that folder, so you have to copy it there again to debug again.

Of course you want to make sure to build in debug mode. Some projects are set up with dependencies on the \release\ directory, which I think is a bad idea, but it's a fact of life sometimes. If you don't want to change your build to Debug, you can quickly change your Release build to emit debug symbols: open the properties page for the project—make sure Configuration is Active (Release)—and on the Build tab, check “Define DEBUG constant” and uncheck “Optimize code” (you may also have to click the Advanced button and select "full" symbols). Now building in release mode will include debug symbols. Be sure to change these settings back once you’re done.

Attaching the debugger to the right process

A number of people have asked me about the "Attach Debugger" menu item they see me use. This is a community feature that's been around for more than a year, but it's good to refresh people's memory of this extremely useful tool.

A SharePoint product team blog entry discusses the Attach Debugger feature that you can install for SharePoint pages. It has a link to the CodePlex project SharePoint 2007 Features that you can install to enable this feature on the Site Actions menu of your sites:

Extremely helpful! And as a bonus, it seems faster than doing it from Visual Studio's Attach Debugger command.

I recommend you look at the SharePoint 2007 Features project, it's got lots of goodies besides this.

Technorati Tags: SharePoint Development

List of MOSS Timer Jobs

markarend — Sat, 06 Sep 2008 16:26:00 GMT

MOSS has many default timer jobs; information about them can be useful to understand the workings of your MOSS farm, and potentially to troubleshoot problems or plan for related types of customizations.

The attached document provides a list of all MOSS timer jobs provided out-of-box, with some additional notes about them.

Consolidated list of MOSS items

markarend — Sat, 06 Sep 2008 16:16:00 GMT

Sometimes you just need a list of things provided by MOSS, in order to plan what kind of things you will make available to users within your architecture.

The attached document lists all out-of-box Lists, Web Parts, Site Templates and Site Actions provided out-of-box by MOSS, along with their descriptions and availability.

MOSS Usage Reports explained

markarend — Sat, 06 Sep 2008 15:55:00 GMT

The site usage reports that MOSS provides are fairly simple, but can be useful if you haven't got any other tools for tracking site usage. One problem with them, however, is that the information they present is not really explained anywhere. Columns are often named "Value" and sometimes it's not clear exactly what the value represents. Another example is what does "Requests" actually measure? The answer is that Requests always measures Page Views, not all HTTP requests for individual items like images, style sheets, etc.

The attached document gives clear, detailed explanations of all out-of-box report elements.

Colleagues, Social Distance & Relevance in People Search; Social Networking tools

markarend — Thu, 01 May 2008 16:16:00 GMT

MOSS provides some very powerful features to enable the new buzzword "social networking." Discussions about these can be found pretty easily, and I give an overview of some tools near the end of this posting. But specifics about how some of the details work has been devilishly hard to find... until now. Through discussions with various people in-the-know, I've been able to assemble answers to common questions around People Search and MySite web parts.

Social Distance

By default, the results on the People Search page are ordered by Social Distance. What the heck is that? It's an ordering of results based on colleague relationships. Here's how it's computed:

Search results are always returned to the search results page sorted by relevance.
When viewing results by social distance, additional processing on the search results page is used to group the results:
- The first 3 pages of search results are grouped by colleague-ness: first your colleagues appear, then colleagues of your colleagues, then everyone else.
- Within each group, the ordering is still by relevance.
- When paging through results, another 3 pages of results will be grouped once you reach page 4, then page 7, etc.

By default, 10 results appear per page, so this groups people in batches of 30. If you customized the People Search results page to show 25 results per page, this would group people in batches of 75.

There are potentially some quirks with this algorithm that was designed to give the best value in a lightweight manner. Your colleagues will appear at the top of the list on page 1, but if you have lots of colleagues, more of them might appear on page 4. This is because the colleague grouping takes place on the client, starting with a relevance ranking. So if some of your colleagues are relevance-ranked after 3 pages worth of results, these will be grouped once you get to the next set of 3 pages (page 4, page 7, etc). Based on relevance, these people should be less relevant to your query.

The People Search results page allows you to toggle the results ordering to only Relevance, ignoring the Social Distance grouping.

Relevance

Relevance ranking in people search is the same as that used in regular search across lists and documents. I'm told that the ranking algorithm MOSS uses in all cases is BM25F.

Conceptually, a user's profile is treated as a document about that person with their name as the title. At a basic level, the more search query terms that appear in the person's profile, the more relevant the result. Matches against a few special fields (e.g. name, alias) are returned in the high confidence webpart.

Note that the names of discussion lists that a user belongs to are included in that user's profile information. This means that a people search for "rock climbers" should return all of the people who are members of a distribution list named "Rock Climbers at Contoso" as well as anyone who has the phrase "rock climbers" in their profile information, such as in their "About Me" field.

Colleagues

Here's where the real value of social distance and other meaningful relationships is computed.

A list of your colleagues is stored in the profile database. During a profile import, this list is initially populated with a set of "immediate colleagues" that are computed from your profile properties: manager, peers and direct reports. This way, when you first look at your Colleagues web part, it's not blank.

Then, from an editing page on your Profile, you can edit your colleagues list to add & remove specific people, and to group them and set their visibility to other people. Also from here, you can ask SharePoint to suggest other colleagues, and these suggestions are collected from several places.

My Microsoft badge photo, 1999!

From your MySite page (or your Profile page, which is available even if MySites are turned off), click Colleagues to edit your colleague list.

Where do colleagues come from?

Immediate colleagues
...automatic: during profile import; comprised of:
- Your manager
- Your peers (others who report to your manager)
- Your direct reports
Colleagues added by you
...manual: via editing page on your Profile
Suggested colleagues
...lookup: manually guided via editing page on your Profile; comprised of:
- Sent items in Outlook. Periodically (every 5 days or so, depending on usage) Outlook analyzes Sent Items for common recipients, weighted by frequency of contacts and other factors. This is how Outlook is able to suggest likely recipients when you begin typing their name in the To: line, and in my experience, it seems to work pretty well. When you click Suggested colleagues, it collects these names from Outlook via an ActiveX control, and adds them to the list of suggestions.
- Office Communicator contacts are examined; that is, those contacts that you've added to your Office Communicator client from the company directory. These are also collected from the Communicator client via an ActiveX control.
- Site Memberships are all sites in which you are explicitly included in the "~Members" group for the site (where ~ is your site name). Other users who are also explicitly included in the ~Members group on those sites are suggested as your colleagues. This information is collected by a WSS profile synchronization timer job.
- DG (Distribution Group) Memberships are examined for suggestions. Distribution groups stored in AD are collected during the AD import.

Colleagues from these sources are collected and the top 20 or so are displayed as suggestions when you click "Add Colleague" on your colleague editing page. It's not fruitful to pursue a more detailed understanding of this calculation, because the recommendation for improving the "quality" of colleagues found is the same: people associated with items you access more often are more likely to be suggested as your colleagues. If you don't like the suggestions, you can remove individuals from the suggestion list one by one or all at once from this page, then get a new list of suggestions.

Privacy

Whoa! Is SharePoint looking at my email? I don't want that, how do I prevent it?

First, SharePoint's not looking at your emails. It gets information about who you sent emails to by asking Outlook for that information. Second, it will never do this without asking your permission. You can always say no:

If you say Yes, then SharePoint will assemble a list of suggested colleagues for you, and you can accept or reject these suggestions. But even if you say No, you can still edit your colleagues to search for and add new people, and to set the privacy of who should see that they are your colleague (Everyone, My Colleagues, My Workgroup, My Manager and Only Me):

Social Networking tools

Why did we go through all this trouble to try and figure out who your colleagues are? Social Networking, baby! We spent a good bit of time on the inputs and the outputs of this to make it a really useful function, instead of just paying lip service to it.

The inputs are the information about who your colleagues really are. A simple option would have been to just provide a place for you to register your colleagues, and not go through all this supposedly intelligent guesswork. But that would have made it almost useless, because most people are just not going to take the time to populate this list, and even fewer will maintain it as their colleagues change over time, which is natural.

SharePoint uses the information already embedded in your company's infrastructure and the changing data you deal with on a daily basis to help you connect with the right people.

Sounds like market-speak, but that's really the goal and I think it does an amazing job.

The outputs are the tools that SharePoint can provide based on this colleague information. Consider some of these details:

People Search ranking by Social Distance. By default, the top people returned when you search for a name will be the people you most likely want to find: people you've communicated with recently, perhaps as a participant on an email thread or a collaborator on a site, and now you want to find more information about them.
In Common with You web part on My Profile page. When you view someone else's profile (for example, by clicking their People Search result), this web part shows you a list of people that you both may have in common. This is useful to quickly understand business relationships that you may need to know about. Categories shown are
- Manager we both report under
- Colleagues we both know
- Memberships we both share
Colleague Tracker web part on MySite. This shows you recent changes to user properties of your colleagues, effectively a newsletter of what's new with people you work with. Information you can track includes
- Anniversaries
- Profile property changes
- Membership changes
- New documents this person has posted
- Out of Office status
- Blog postings from this person
Colleagues web part on My Profile page. This displays your current list of colleagues, grouped into categories that you may have applied.
Memberships web part on MySite. This shows Distribution Lists and SharePoint Sites of which you are an explicit member. For SharePoint Sites, it is rather specific: you must appear as an individual member of the ~Members group on the site (where ~ is the site name). If you have access to the site through a different configuration, such as being a member of the ~Owners group, or being a member of an Active Directory Security Group that is a member of the ~Members group, this is not counted. Otherwise, everyone would very likely see all the portal sites displayed as their memberships, and that would not be useful.
Organization Hierarchy web part on My Profile page. This shows your manager, your peers (others who report to your manager) and your direct reports, if you have any.

These are some of the tools that MOSS provides for Social Networking; I've highlighted the ones that use profile data and the powerful "colleague" pattern to show meaningful relationships among people. For a better introduction to the full set, see the product team's Enabling and Managing Social Networks for Business use with MOSS.

Technorati Tags: SharePoint,Social Networking,MySites,People Search,Social Distance

Test With Correct Privileges

markarend — Fri, 07 Mar 2008 00:12:13 GMT

When developing web parts and other components with code, it's important to remember that operations performed by code may require certain privileges. During development, the code runs in the security context of the developer, who is usually a server administrator. This means all operations are permitted, so access problems don't arise. During testing and production, however, the security context of the code may be different because it's being invoked by testers and end-users.

Therefore, all components should be tested with several end-user accounts: one would be the developer’s account which is usually a server admin; that’s how most people do their unit testing. But tests should also be made with an account of minimal privilege, say Visitor. Some components might be doing things with the object model that will only work when an administrator invokes it. If this turns out to be the case, a technique called “elevation of privilege” can be used to overcome it. See MSDN article Running Commands with Elevated Privileges in Windows SharePoint Services 3.0 for an explanation of doing this.

What code needs to be tested using different privileges?

1. Code that's invoked as the result of an end-user action. An example is a custom web part that is displayed on a page. The end-user opens the page and this is what invokes the web part code under the user's security context. A counter-example is timer job code that is invoked by SharePoint.

2. Code that uses the SharePoint API. This is typically where security errors arise. If a component does not use the SharePoint API, then chances are it will not need to elevate its privilege. To be entirely sure, it should be tested at minimum privilege, but this criterion can be used to prioritize testing of other components higher.

How can a developer test with different accounts?

The simplest approach is to create three accounts "Test Visitor," "Test Member," and "Test Owner" in Active Directory and then to add these accounts to matching groups on the test sites.

First, the developer must decide in what security contexts the component is supposed to work. For example, most end-user web parts should work for users signed on as Test Visitor. On the other hand, an stsadm extension is only invoked by a server admin and should not be tested with a minimum privilege account.

"Sign on as different user" can be used to choose one of the test accounts as appropriate; however, in some cases, this approach does not seem to “stick” based on browser state or browsing behavior (e.g. browsing to My Site when browser is configured for automatic logon). The best way to ensure that the desired account is used is to configure the browser to always prompt for credentials, then to open a new browser window to begin testing. Then, re-run all unit tests that exercise the component directly (not, say, the deployment of the component).

Technorati Tags: Minimum privilege,Web part security,Code Access Security

Using Reflector to See SharePoint's "Source" Code

markarend — Fri, 29 Feb 2008 00:49:00 GMT

Important Note: Customers are advised to review the end user license agreement (EULA) for the relevant Microsoft products before using this tool. This blog entry does not authorize or endorse any use of Microsoft products that is not addressed specifically by the product's EULA.

Do you sometimes use a "reflector" program to examine SharePoint source code? This can be necessary to:

Understand out how SharePoint is doing something, to find what elements can be customized.
Understand what members to override in classes you create that inherit from SharePoint classes.

The de facto standard program for doing this is Lutz Roeder's Reflector. The MSDN article on ten must-have tools has a great description of how helpful it can be and how to use it.

One thing the article doesn't tell you is where to find SharePoint's assemblies; fortunately it's not that hard. Click "Open" in Reflector, then with a little bit of browsing, most people easily find the dlls in the ISAPI directory of the "12-hive" (C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\ISAPI).

Open one or more of these dlls, then browse the classes to see how SharePoint's put together… the Disassemble tool is exceedingly useful! Note: the code you see is reconstructed from MSIL, into the language of your choice (C#, VB, Delphi, C++ or Chrome)… the product teams didn't really use all those goto's!

However, some SharePoint namespaces seem to be missing or incomplete when viewed in Reflector. This had me baffled for quite some time, until I found the following.

Some SharePoint assemblies are stored in the _app_bin directory of the web application instead of the ISAPI directory in the 12-hive. Presumably, the reason for distributing certain code into the web application's root is related to something like stability, security or scalability. But the important point is if you're using Reflector to look at SharePoint code, you may need to look here as well.

This is especially true for a namespace like Microsoft.SharePoint.ApplicationPages. Two assemblies contribute members to this namespace: 12\ISAPI\Microsoft.SharePoint.dll and Inetpub\...\_app_bin\Microsoft.SharePoint.ApplicationPages.dll. If you just reflect the one in ISAPI, you'll see very few members; the ones you typically want to look at are in _app_bin!

SharePoint DLL locations

Here's a list of all the SharePoint assemblies and where they appear.

12\ISAPI

Microsoft.Office.Excel.Server.Udf.dll
Microsoft.Office.Excel.Server.WebServices.dll
Microsoft.Office.Policy.dll
Microsoft.Office.Server.dll
Microsoft.Office.Server.Search.dll
microsoft.office.workflow.tasks.dll

Microsoft.SharePoint.dll
microsoft.sharepoint.portal.dll
Microsoft.SharePoint.Portal.SingleSignon.dll
Microsoft.SharePoint.Portal.SingleSignon.Security.dll
Microsoft.SharePoint.Publishing.dll
Microsoft.SharePoint.Search.dll
Microsoft.SharePoint.Security.dll
microsoft.sharepoint.WorkflowActions.dll

Not .NET assemblies (can't reflect):
OWSSVR.DLL
SHTML.DLL
SSOCLI.DLL

Inetpub\wwwroot\wss\VirtualDirectories\<web app>\_app_bin

Microsoft.Office.DocumentManagement.Pages.dll
Microsoft.Office.officialfileSoap.dll
Microsoft.Office.Policy.Pages.dll
Microsoft.Office.SlideLibrarySoap.dll
Microsoft.Office.Workflow.Pages.dll
Microsoft.Office.WorkflowSoap.dll

Microsoft.SharePoint.ApplicationPages.dll

stssoap.dll

Obfuscation tips

Sometimes, not too often, when Reflector is disassembling source code for you, it will show "This item is obfuscated and can not be translated" instead of code. I think the product team did this for some of the more "sensitive" areas of the code (such as LogInAsAnotherUser) and also on a bit of a random basis, perhaps to prevent fully reverse engineering the product. In any case, by changing the translation language to IL in Reflector, you might get enough information from the MSIL code to answer the question that drove you there in the first place. For example, sometimes I just need to know what modules are being called, or what strings are being used to find other resources in the 12-hive; these are still visible in MSIL.

Important Note: Customers are advised to review the end user license agreement (EULA) for the relevant Microsoft products before using this tool.

Technorati Tags: SharePoint,MOSS+2007,Development

MySite Pages and Architecture

markarend — Sat, 23 Feb 2008 07:03:00 GMT

MySites are very interesting on many levels. When you start to think about how to architect, deploy or customize them, you may encounter some initial confusion and a lack of detailed information. For instance, did you know that your MySite's Home page and the My Profile page are in completely different site collections? What's up with that?

The reason is that a My Profile page is provided for every user in the portal regardless of whether they have a MySite, or even if MySites is disabled. Actually, a single page renders every MyProfile page: http://mysite/person.aspx. This page has code that displays a "Home" tab linking to the user's MySite at http://mysite/personal/userid/default.aspx if it exists. The Home tab makes it appear that these two pages are part of the same site. But the URLs hint at the truth: the My Profile page is on one site collection, while the user's MySite Home page is on another.

You knew each MySite is hosted in its own site collection, right? When a MySite is created for a user (see below), that user is added to the Owners group for the new site collection, and is also added to the Site Administrators list. This user has full power over their MySite. To customize that is a bit difficult, but possible.

I created a Visio diagram that depicts the relationships between the pages, where profile information is used on them, and how the links between them interact.

Screenshot (click to download the diagram)

What happens when you browse to http://mysite/?

Whenever you browse to http://mysite/, you're redirected to http://mysite/personal/userid/default.aspx through a few steps:

http://mysite/default.aspx inherits from Microsoft.SharePoint.Portal.WebControls.MySiteHostHomePage. This assembly authorizes the user against the MySite shared service rights (can be enabled/disabled by users or groups), then emits an HttpResponse.Redirect to either /_layouts/MySite.aspx or /_layouts/AccessDenied.aspx, accordingly.
/_layouts/MySite.aspx inherits from Microsoft.SharePoint.Portal.WebControls.CreatePersonalSpace. This assembly examines the user profile property Personal site.

If the Personal site property is blank, CreatePersonalSpace creates a new MySite site collection for this user, then stores its relative URL (e.g. "/personal/userid/") in the Personal site property.
CreatePersonalSpace then emits an HttpResponse.Redirect to the URL in the Personal site property.

You arrive at http://mysite/personal/userid/default.aspx, where "mysite" is the URL of the web application hosting your MySites, and "userid" is your user id.

Note, other configurations could change this URL, such as the Personal Site Location ("personal") and the Site Naming Format (whether "userid" should include your domain.) These settings are found on the SSP Admin page "My Site settings."

Customizing MySite

Steve Peschka has the best information for customizing MySites, including how to set a custom master page automatically for all new MySites being created... this one's not obvious! Steve has a very clever approach that uploads an XML file to each new MySite, containing instructions on what should be modified. Then, a control in the custom master page reads the XML file and performs the customizations. He explains why this approach is necessary.

His XML spec for customizations provides several things you can do, such as removing/adding web parts and modifying QuickLaunch links. He doesn't provide a way to change the permissions of the owner... look for another blog posting from me on how to do that when you want to restrict the rights of each MySite's owner.

See also
To enable/disable MySites, Managing MySite Creation and Usage.
If MySites are disabled, Where is My Picture stored? What if MySites are off?

Searching Resource (resx) files

markarend — Sat, 26 Jan 2008 02:21:00 GMT

Often, a request comes to customize some of the text that SharePoint displays. And often, that text is stored in one of SharePoint's resource files, so it's just a matter of finding the right one. But I've noticed that Windows explorer doesn't do a very good job of searching inside *.resx files. In fact it behaves as though it just skips these files. Of course, you can open the resx files in Visual Studio to search them, but they appear in many different directories, so it can be a bit of a headache just to get them all opened.

After needing to do this for about the 30th time, I decided to make searchable copies of SharePoint's resx files... easy enough, just save them all as xml. For your convenience, here they are in one zip file.

Download: http://code.msdn.microsoft.com/SearchMossResources

SharePoint Lists as DataTables

markarend — Sat, 26 Jan 2008 01:50:00 GMT

You may know that SPList can return a DataTable type: SPList.Items.GetDataTable(). And if you've worked with this, you may know that the DataTable you get is not databound to the list. This means you can't update the List from changes you make to the DataTable. In addition, if the List is empty, the DataTable you get back won't have any schema information. I don't know if that's a bug, but it's certainly a pain.

I wrote a code sample to overcome these problems by providing a new type: ListDataTable. Instantiate an object of this type with the URL of a list, and it behaves like a DataTable connected to the list. You can perform Insert, Update and Delete queries on the ListDataTable, then just call Update() to save those changes back to the list.

Download: http://code.msdn.microsoft.com/ListDataTable.

Important Guidelines

"Wow, I can use SharePoint like a database? Even making join relationships between lists?" Hold on, there, Skippy. Yes, it's possible, but maybe not so desirable. Consider what you want to accomplish and why. You can use Excel spreadsheets like a database with joined tables, too, but it's not usually a good idea. SharePoint and Excel are designed for user interaction, not serving data to applications... so this approach may not scale arbitrarily.

Recommendation 1: use the ListDataTable type to help you manipulate data in SharePoint lists with the power and flexibility of queries.

Recommendation 2: Don't forget Microsoft Access... it's a fantastic tool for manipulating SharePoint lists. On a list's DataSheet view, click the long, thin toolbar tab to the right of the datasheet. This opens options for linking to Access. Or, from Access, open your SharePoint lists directly. You can really clean up data in big lists in a hurry with this approach.

And Sahil Malik has another technique for treating lists like tables: creating a join using a DataView web part from SharePoint Designer 2007.

Master Page stsadm commands

markarend — Fri, 25 Jan 2008 06:56:00 GMT

Have you ever wanted to use stsadm to view or manipulate a site's master page? Unfortunately there are no default commands to do so. But stsadm is easy--and fun, some might even argue--to extend.

I wrote a sample project that you can use to perform the following functions:

stsadm -o ShowMasterPage -url <site url>

stsadm -o SetMasterPage -url <site url> -masterpageurl [<page url> | Parent]

This can come in very handy for troubleshooting and fixing problems with some master page deployments. The code is on MSDN's new "Code Gallery" which is very much like CodePlex, but designed for the smaller, quicker samples that don't need to be full-blown collaborative projects. I thought I'd try it out.

Download: http://code.msdn.microsoft.com/masterpagecommands.

Trial Period [Evaluation Period] for this product has expired

markarend — Thu, 08 Nov 2007 18:19:00 GMT

I was still getting this error on one of my VPCs, and found some blog entries with a little difficulty. Thought I'd post another to make it easier to find. One thing is, there are two possible issues that are known to cause it.

StandaloneDCWorkaround

If the machine you're running on is a Domain Controller, and you have installed MOSS as "Standalone," then you need to execute a fix to avoid the expired error. A standalone installation is one where MOSS installs its own database management system, and is not connected to an existing instance of SQL Server. A standalone installation will always have exactly one server in the farm, not multiple servers.

Microsoft has published a fix for this, available at http://download.microsoft.com/download/b/1/a/b1a6dceb-92a3-4808-8dac-b4e40c90ce00/StandaloneDCWorkaround.msi. Just download this and run it on the Domain Controller where you're experiencing the problem. (If you don't want to because this is a Domain Controller for your organization, why did you install MOSS on it, especially in standalone mode? Get a development server for that.)

Application Pool Identity

If you don't have a standalone installation, you may still get the expired error. This answer should fix that case.

The Identity used for your SharePoint site's Application Pool must be a Domain account with local server access. If you're using a machine account (such as local user, or NETWORKSERVICE), it may work under most circumstances but give the expired error for some operations. Therefore if you encounter this error you have to make sure you are using a domain account for the app pool identity.

Note, I've observed that the identity of OfficeServerApplicationPool keeps reverting to NETWORKSERVICE, so I can’t use this for my MOSS web application. Apparently this machine account does work for the Central Admin site, and SharePoint ensures that it's restored to this value if you change it.

Self Service Site Creation

markarend — Thu, 08 Nov 2007 18:09:00 GMT

By default, in Microsoft Office SharePoint Server 2007 (if you are using the Corporate Intranet Portal template as your default site) when you go to the “Sites” link and click the Create Site button…SharePoint creates a subsite as a member of your portal’s site collection. This is great if within your organization, you want to easily share things such as templates, site columns, content types and navigational elements. Plus security and user management is much easier using this approach.

However some organizations will still require unique site collections since their business units are very unique and very little sharing is anticipated between groups. If that is the case, then you may instead wish the Create Site button to create site collections. To do this, you need to:

Enable Self Service Site Creation in Central Administration
Change behavior of the Create Site button on Site Directory

Enable Self Service Site Creation in Central Administration

Open the Central Administration site
Click Application Management
Click Self-service site management
Select the correct web application (that step is easy to miss)
Select On for Enable Self-Service Site Creation and click Ok.

Change behavior of the Create Site button on Site Directory

From the portal, use the Site Actions menu, select Modify All Site Settings. If you are not on top level site you will need to go to Top Level Site Settings.
Under site collection administration, select Site Directory Settings.
Select the checkbox to create new site collections from sites directory.

Gavin Adams describes how to manage permissions for Self-service site creation.

Scripting STSADM commands

markarend — Thu, 08 Nov 2007 18:02:00 GMT

This posting contains tips 'n tricks for using STSADM commands within batch files.

Note, the primary Microsoft reference for STSADM: TechNet article Stsadm command-line tool (Office SharePoint Server).

Testing results

STSADM returns 0 as ERRORLEVEL in DOS when it succeeds, or -1 when it fails. To test for success, IF %ERRORLEVEL% EQU 0 can be used.

Redirecting output

When scripting stsadm, sometimes it’s desired to redirect output to a file, using the “>” operator. This works as expected, but if stsadm displays error messages from executing its requested operation, the messages still go to the screen and not into the file. This is because DOS has two standard output devices, stdout and stderr. The > operator redirects stdout only. Fortunately, we can add another operator that will redirect stderr to stdout so that all messages go into the output file:

stsadm -o addsolution -filename MySoln.wsp >output.txt 2>&1

>& is a command redirection operator. Stderr is handle 2, and stdout is handle 1. Therefore, 2>&1 means redirect stderr to stdout. Since we've already redirected stdout to output.txt, then all messages will now go into this file.

See Microsoft article Using command redirection operators for further applications of this and related operators.

Finally, remember that >> will append messages from stdout to the specified file instead of overwriting; >>output.txt 2>&1 works to append all messages and errors.

Asynchronous commands

Some stsadm commands create a timer job to execute the operation so that it may be executed on multiple farm servers. Commands that use the following modifiers may behave this way:

-immediate Use a timer job to execute the operation on all applicable servers immediately… the job will start within one minute.

–time <time> Use a timer job to execute the operation on all applicable servers at the specified <time>.

-local Execute the operation on the local server immediately; return only after operation completes.

When using -immediate or -time, stsadm will return after creating the timer job. However, the operation itself will take a little while longer to finish its execution. This can become a problem in scripts such as

stsadm -o retractsolution -name mysolution.wsp -immediate

stsadm -o deletesolution -name mysolution.wsp

Here, the second command will fail because the retractsolution operation will not have been completed on all servers yet. The simplest fix that can be recommended is to ask for human intervention:

stsadm -o retractsolution -name mysolution.wsp -immediate

echo Wait for mysolution.wsp to be retracted across farm

pause

stsadm -o deletesolution -name mysolution.wsp

Note that the stsadm command execadmsvcjobs might seem to offer a clever solution, because it will cause outstanding deployments to complete synchronously. However, this command affects the local server only, so the same situation still exists on a multi-server farm.

Customer stsadm scenario… with a challenge

Many customers have requirements to deploy required configurations to their farm; this typically means they must deploy to several environments such as Dev, UAT and Production. They want to script these configurations whenever possible so that the process can be automated. Stsadm supplies operations to set some configurations, but not all. In addition, some of the ones that it does not cover can be very tedious to configure manually, such as search scopes, profile properties and audience definitions.

In these situations, creating an stsadm extension is a great approach to setting these configurations in an automated way. It matches the approach of scripting default stsadm commands to execute in different environments. Also, stsadm extensions can be deployed as other customizations are deployed, using SharePoint Solution files.

A flexible way to design these extensions to supply an import/export pair of operations. This way, a developer can configure their SharePoint instance to have the appropriate configurations, then use the stsadm extension to export the configuration settings as an xml file. On the UAT and Production farms, the stsadm extension can then be used to import from the xml file to make the appropriate configuration settings. This approach allows the process to be maintained throughout production, usually without requiring the developer’s involvement for further changes.

One challenge with this is deploying and executing the stsadm extension. These two operations should be performed as separate steps, because the deployment must be fully completed before attempting to execute. On a local server, a script can ensure the deployment step is complete by using the -local argument, but on a farm with multiple servers, the deployment must use -immediate, which executes as soon as possible, but asynchronously.

To do both operations in a script, it is necessary to wait for deployment explicitly, as shown in the following example:

stsadm -o addsolution -filename ImportProfileProperties.wsp

stsadm -o deploysolution -name ImportProfileProperties.wsp -immediate -allowgacdeployment

echo Wait for ImportProfileProperties.wsp to be deployed across farm

pause

stsadm -o importprofileproperties -filename RequiredProperties.xml

Where is My Picture stored? What if MySites are off?

markarend — Thu, 08 Nov 2007 17:47:00 GMT

MOSS user profiles have a property called Picture, which can store the URL of an image file. When this property is filled in, other MOSS features display the user's picture at useful times: in search results, or on a MySite. But where's the image file stored? It depends on whether MySites are enabled or not.

If MySites are enabled, then the profile editing page provides a "Choose Picture" control that allows you to easily upload a picture to be associated with your profile: just click the control, browse to a picture on your PC, and click Ok. This control uploads the image file, stores it into the Shared Pictures library of your MySite, then copies its URL into the Picture property of your profile.

But what if you haven't created a MySite yet, or if MySites are disabled?

If you haven't created a MySite yet, then chances are you won't be on the profile editing page. The typical path to get to the page where you choose a picture is to go to your MySite first. If you have no MySite, it will be created for you at that time. From there, click the Detail link on MySite to edit your profile information. But it's still possible you could get to this page without going to MySite first. In that case, either MySites are disabled (see next case), or you got here by entering the URL directly. In that case, you'll see an error message in the upload control indicating that you don't have a MySite yet.

If MySites are disabled, you can still browse to http://mysite/Person.aspx to view your My Profile page, then click the Details link to edit your profile data including Picture. This time, the Picture field is still present, but the "Choose Picture" button is gone. In its place is a plain text field, so you can enter the URL of an image file. This means you have to upload the image file to a site you can access, then copy its URL into this field. This is probably not the smoothest experience for most users.

Administrators planning to disable MySites should be aware of this, if they're also planning to allow users to edit their profile. One choice might be to edit the behavior of profile properties via Central Admin to lock the My Picture field against edits, or even hide it completely if desired.

See also
How MySite pages are organized: MySite Pages and Architecture.
To enable/disable MySites: Managing MySite Creation and Usage.