eChef

SORT ‘09 Conference Presentations

2009-11-11T06:21:00.001-07:00

For those that were able to attend the SORT conference last month, sorry for the delay in getting this code available to you, but hopefully it was worth the wait!

Aaron and I appreciated the kind words in the feedback forms… Overall, the four sessions averaged a 8.5 rating, with our “Design” session getting over 9.0! Thanx again!

So here is the presentation and my demo notes for the “SharePoint Development without code” session. Included is the source for Todd Bleeker’s Style Under Cursor javascript. Check out his site, he’s got a lot of other great helps for both developer and power users.

Here is the “Design” session. I’ve included the presentation, as well as a copy of the minimal master from Heather Solomon, and the customized master page with it’s CSS that we worked on in the demo. Feel free to use it, modifying it, whatever… it’s yours!

In the Web Services demo, we went through a LOT of material… On of the feedback rightly said that this would have been better served over a few hours rather than 45 minutes, and rightfully so! I’ve included the presentation and all the source code we looked at, both the Custom Web Service and the Web Service consumer. You will need to add the Microsoft.SharePoint.dll file to the External References folder to compile the code. You can get this out of either the free MS WSS 3.0 download or from a MOSS 2007 installation.

We ended up not giving the Web Parts demo, as the majority of the audience was actually not development staff, and so held an ad-hoc Q&A session, talking mostly about possible solutions to specific challenges, namely Data View Web Part utilization, 3rd party add-ins, and List View Views and filtering. For those interested, here is the presentation. It also includes the code for a SQL server Web Part Viewer. Again, you’ll need to add the Microsoft.SharePoint.dll file to External References.

Hope you enjoy, and thanx for participating in a great Conference!

Josef Nielsen (echef)

Preliminary Results from the MOSSPit User Survey

2009-06-30T11:59:00.001-06:00

So here are a couple of preliminary results from the MOSSPit (Utah’s SharePoint User Group)… I found these quite interesting!

The two largest audiences are definitely the Developer (#1) and the Farm Administrator (#2).

Again, Development appears to be one of the biggest interests within the User Group. Additionally, SharePoint Designer (#2) and Web Services (#3) were of high interest. In 4th place there was a 4-way tie between Automation and Scripting, InfoPath Forms, Security, and SQL Server Reporting Services. Overall, there was a fair amount of interest across the board on most topics, however.

If you are in the Utah area, and want to participate in the MOSSPit Survey, check it out and let us know what you think!

April MOSS Pit Presentation...

2009-05-19T13:06:00.002-06:00

We had a great presentation last month from Doug Davis, the Product Director for SharePoint at Quest Software at the Utah SharePoint Users Group. He utilized a slide Deck of some infamy that Joel Oleson has presented numberous times. You can get a copy of it from the MOSSPit.

This upcomming month we will be fortunate enough to hear from Ryan Day, of IHC. Ryan will be showing us how to do some pretty cool stuff with the "out-of-the-box" SharePoint Web Parts. There will also be food and great give-aways! Don't miss it!

MOSS Pit (Utah SPUG) Workflow Presentation

2009-04-13T14:15:00.001-06:00

Adam recently got us an updated copy of the presentation he gave last month for the MOSS Pit, the Utah SharePoint User Group. You can get a copy of it here.

He also sent in a great write up on the presentation he gave with Screenshots and he detailed what went wrong at the end of the presentation, and how to avoid it yourselves! Check out a copy here.

Thanx Adam!

MOSSPit Branding Presentation

2009-03-03T12:44:00.001-07:00

Today I presented at the Salt Lake City SharePoint User Group on SharePoint Branding... I've included my slide deck, and some of my speaking notes in the slides here, if you'd like a copy.

The 4 categories hit upon (high level, with a few specific examples) were Out-of-Box Styling, Theme Modifications, CSS Override, and Custom Master pages and CSS.

Thanx to the whole MOSSPit crew for pulling together the meeting, and supporting this communitee effort!

Excel Services and Web Gardens

2008-11-18T11:09:00.001-07:00

I haven't seen too much on this, and it caused me some pain, so I thought I'd share... We use very large Web Servers (24GB) with Web Gardens to utilize all that memory.

The problem comes in with Shared Services. Most Shared Services operate perfectly fine in a Web Garden. Excel Services, specifically with Charting, is an exception. For some reason, perhaps performance related, ECS will generate Charts using two separate requests to the Shared Services, one for the workbook, on for the Chart Image.

The problem is that when sending in the second request, more likely than not you will get a difference process thread in the Web Garden than your original request. This creates a disconnect, as they are not separate autonomous requests, but are linked.

The result is a wonderful ECS error on your page that says "Failed to Download Excel Services Chart". This is backed up by MOSS log files that indicate that a "SOAP exception occurred" during "ExceuteWebMethod" in GetImage. The actual error will show as a session timeout (because of inactivity).

The fix is simple. Shared Services cannot have multiple threads. You can set this in the properties of the Application Pool. Just go to your IIS manager (on each WFE server) and right-click the Application Pool for Shared Services. On the Performance Tab, change the Threads value back to "1". No more Web Garden for Shared Services. You can Web Garden your Content Web Apps without and surprises, just not your Shared Services.

You can see the full Log entries in this Discussion Board...

Automated Farm Installations, part 3

2008-11-11T13:34:00.001-07:00

So here is the last installment in this series, the Extra's... In Part 1 we installed the product and did the base configuration... In Part 2 we configured the SharePoint Server Shared Services and got rid of that annoying Red warning test on the Central Admin Site. In this installment, we are going to look at above and beyond functions, like:

Creating additional Web Apps
Enabling Self-Service Creation
Alternate Access Mappings
Managed Paths
Installing Features and/or WebPart Packs
Attaching Content DBs

Creating additional Web Apps is very simple. We use the same command we used earlier, ExtendVS. This is valuable in many places. For a new farm, you can have it create your root web as well, although this is generally something I recommend against. The reason is that configuring your Web Application Creation Scripts without the Root Web prepares your script for Disaster Recovery in the future.

If you have existing content and are using your install scripts to recover, you must make sure that you do NOT create the root web... Doing so will prevent the ability to recover your original root web via attaching Content DBs. I use this as a standard, and manually create the Site Collections (either via GUI or STSADM Script with CreateSite or CreateSiteInNewDb).

Again, if you are preparing your script for DR, I recommend creating the Web App with a dummy Content DB, and adding a command to remove that DB at the end of the script, after your attach DB command(s). If you want to remove that DB manually, make sure you add a comment at the end of your DR script to remind yourself, or you may be in for a surprise a few days after a DR recovery!

Self-Service Creation is for "team" or self-provisioned environments, and is enabled using the EnableSSC command:

stsadm -o enablessc -url http://sharepoint.domainname.pri:80

This is handy to enable automatically on setup, but for DR purposes, you have to remember that this cannot be enabled unless the root web exists. If recovering Content DBs, you need to create the Web App with no Root Web, Reconnect the Content DB(s), and then enable SSC, once the Root Web is online again.

As you setup your Web Applications, it is good to configure any Alternate Access Mappings you may need (ie, Extranet, Intranet, etc.) The AAM can be configured per Web App by script using the AddAlternateDomain command, which looks a bit like this:

stsadm -o addalternatedomain -url http://sharepoint.domainname.pri:80 -incomingurl http://intranet:80 -urlzone intranet

Which would allow your SharePoint site to respond to http://intranet as well as http://sharepoint.domainname.pri. This does not do anything for name resolution though. All DNS/NetBIOS resolution is still up to you to configure on your network, this just allows SharePoint to respond to it when it reaches your servers. A number of different "urlzone" parameters can be used here, including intranet, internet, and extranet.

In the same vein, configuring the Managed Paths of a Web App are also important. Including all Wildcard Inclusions or Explicit Exclusions will save you time and heartache, especially in the case of minimal documentation. Reattaching a Content DB with a Site that lives on a Managed Path that is not configured will not appear accessible until the path has been added to the Web App. I strongly recommend making each Managed Path change by script (rather than manual) and adding that to your master DR script as your first form of documentation. Additional environmental documentation is definitely desirable, however, if you are religious about your inclusion of all farm configuration changes to your DR script, you now have enough to get by.

Managed Paths are modified using the "AddPath" command. It looks something like this:

stsadm -o addpath -url http://sharepoint.domainname.pri:80/project -type wildcardinclusion

Also make sure to remove the "sites" wildcard inclusion if you don't normally use it, or you will find they sprout up quickly in an SSC environment.

With all the Web Apps created and configured, you are almost ready to attach Content DBs. Before doing that, you should install any solutions required by your farm. Installing solutions (and deploying them) is something that, like Managed Paths, should always be carefully documented. I include all custom code (non-OOB software) in this category. If there is a Feature-set that is a commercial product with a full installer, I put a set of comments detailing what versions and service packs of that product are installed, with an echo line to remind the script-runner that there is additional activities required at that point. If it is required prior to the content being restored (or earlier in the process), I recommend inserting the echo statement with a pause. The ideal would be a silent install option scripted right in, but that is not always possible.

For those third-party and home-grown Feature-sets that are compiled in to SharePoint Solutions, you can install them with the "AddSolution" command, and deploy them with the "DeploySolution" command:

stsadm -o addsolution -filename MyCustomFeature.wsp

stsadm -o deploysolution -name MyCustomFeature.wsp -url http://sharepoint.domainname.pri:80 -force -immediate

Lastly, attach your Content DBs to your farm again using the "AddContentDb" command. I strongly recommend issuing an IISReset command prior to this to make sure all changes have taken affect. the Command is formatted like this:

stsadm -o addcontentdb -url http://sharepoint.domainname.pri:80 -databasename WSS_Portal_Content_01 -databaseserver DBServerName\NamedInstance -sitewarning 50 -sitemax 70

This can also be used to deploy schema changes with less farm disruption for larger farms... When deploying schema change patches and service packs, the first node must finish updating the entire farm before things come back online. This can take hours for larger databases, even on big hardware. To minimize this impact, the DB's can be removed from the Web App, taking all the sites offline, then the patches can be applied, then the DB's can be re-attached. this updates the schema in the Content DBs one at a time, bringing each online and accessible after it has finished the update. Although the total time is about the same, the downtime for the farm is less, as you can selectively bring the most critical data online first and roll-through the DBs in a business-criticality order.

Well, this does it for the automated installation series... Hopefully your gotten something useful out of it, as I did while learning about this process. If you want to automate the process of making these scripts, take a look at the CodePlex project I've been working on for this... It is still in an Alpha state, but try it out and see what you think:

NSOT SharePoint Office Server Installation Script Generator

Automated Farm Installations, part 2

2008-10-01T11:36:00.001-06:00

In part 1 I went over some of the basics of why an automated installation is a good idea for not only Development and testing labs, but for QA/Staging environments and even Production.

Part 1 detailed the initial steps in creating a farm, including the scripted installation of the product (copying the binaries) and initial configuration (setting up the farm). In this section, I'm going to talk about the different steps required to finish the installation, or the user configuration. These are the parts of the farm setup that are not done by the wizard if you install SharePoint manually, but are required to "complete" your installation.

One of the things that always seems to annoy developers is that nagging message on the Central Admin page that says in Red "Your Farm is not configured properly!" (I think it is actually stated nicer, but I haven't seen it for a while). These are the steps that are required to make that go away, and "complete" the installation of MOSS.

Indexing/Search - You must configure the Index Server options so you have both the crawl and query functions active in the farm.

Shared Service Provider(s) - you must install and configure at least 1 Shared Service Provider. This is the service mechanism used by MOSS to provide User Profiles, Indexing, and other Shared Services, such as BDC, Excel Calculation Services, Forms Server, and Web Rendering.

Outbound SMTP Server - you must configure the Outbound mail SMTP address for the farm so it knows how to communicate with users and admins.

Excel Calculation Services - You have to enable the ECS role on at least one server in the farm. This allows Excel sheets to be web-rendered.

1st: Required steps to configure Index Server

The Index server is made up of two services, the WSS Search Service, which searches help content, and the MS Office SharePoint Server Search service, which searches user content and other sources. These can be configured with simple STSADM commands.

First, configure the Windows SharePoint Services Indexing Service. This needs to be done on the server that will hold this role. This is done with the STSADM SPSearch command:

stsadm -o spsearch -action start -farmserviceaccount domain\searchaccount -farmservicepassword Password

The parameters mean the following:

-action start: gives the directive to start the indexing on this server.

-farmserviceaccount and -farmservicepassword: The identity and password for searching. This does not have to be your Farm Admin account.

Second, configure the Office SharePoint Server Indexing Service using the STSADM OSearch command, again, on the server that will hold this role, like this:

stsadm -o osearch -action start -role indexquery -farmcontactemail admin@SharePoint.pri -farmserviceaccount domain\searchaccount -farmservicepassword Password -defaultindexlocation d:\index

And the parameter descriptions:

-action start: again, the action tells the service that this farm member will be starting this role.

-role x: The role is what part of the search functions will be running on this machine. you can specify index, query, or indexquery for both roles. For those unfamiliar with this terminology, indexing is the crawling portion of the search role, that will search web pages and create indexes to be searched. Querying is the user-request side of the index service, the side that handles all search requests from a user and provides a list of results. My example shows both roles being assigned, however you can separate these by using this command on multiple servers in the farm with the role specified. An example might be to make all your load balanced Web Front End (WFE) servers Query servers, to handle user requests.

-farmcontactemail: the email address of the admin for the farm.

-farmserviceaccount and -farmservicepassword: the identity information for the indexing service.

-defaultindexlocation: the location for all the locally stored index files, used to add index results by the index role, or to parse results by the query role.

And that's all there is to it. you now have a functional indexing service installed. One thing to note is that this does not configure the actual crawling of content, just the infrastructure to support crawling. you must still specify any custom content sources and crawl schedules in the SSP admin console.

2nd: Required Steps to Install the Shared Service Provider.

Here is what is required to install an SSP:

1) A Web App for the SSP

2) A Web App for MySites (can be a bogus/mock one if you do not plan to deploy MySites)

3) Configure the SSP

Frist, to script the creation of the Web Apps, we turn to the STSADM command ExtendVS, and it ends up looking something like this:

stsadm -o extendvs -url http://SharePointServer:9100 -ownerlogin domain\SPFarmAdmin -owneremail mossadmin@domain.com -exclusivelyusentlm -donotcreatesite -description "SSP - 9100" -databasename SSP_Content -apidname "SSP - 9100" -apidtype configurableid -apidlogin domain\WebAppAccount -apidpwd Password

So here's what it means... ExtendVS is the STSADM command for creating WebApps. It is used for both extending existing ones in IIS, as well as creating new ones. The primary difference is whether it already exists in the metabase as a Web App, or if it is an unknown name. Here are the parameters described:

-url: this is the url and port for the Web App. If no port is specified it does default to 80. By default this will not create a host header, just the URL of the Web App.

-ownerlogin: this is the owner of the Web App... I've heard various theories on who this should be, but I prefer this to always be the Farm Admin Account that you use to create the farm.

-owneremail: same as above, really. Just contact info.

-exclusivelyusentlm: this is for the security level on the Web App. If you will be setting up Kerberos, then you do not want this option, however if that is a long way off, or possibly never, use this flag.

-donocreatesite: by default the ExtendVS comand creates a Site Collection at the root ("/"). For MySites and SSPs, this will break the WebApp so it cannot be used correctly, so you need this flag. This is also handy if you are scripting for DR or restoration purposes, in which case you already have a root site you will want to restore later, so do not want another one to conflict.

-description: the description of the Web Application

-database: the name of the content DB to be created (this cannot be an existing DB. Add existing DB's using the addcontentdb function detailed in the upcoming part 3 installment of this series).

-apidname: this is the name of the App Pool for the Web App.

-apidtype: this is either configurableid or networkservice, depending on what credentials you want the app pool to run under. In most cases this will be configurableid.

-apidlogin and apidpwd: the app pool login and password.

-sethostheader: this one isn't in the example above, but is handy for setting the host header values for the web app based on the url parameter.

So after creating a Web App for the SSP, you'll need to repeat the process for a Web App for your MySites. Both these Web Apps need to be created prior to establishing your SSP. Typically in a "more-secure" model you would use separate identities for the Farm Admin, the SSP Web App and the MySite Web App.

To create the SSP itself, once both the SSP and MySite Web Apps are created, you will use the CreateSSP STSADM operation. Here is an example of the function:

stsadm -o createssp -title "Shared Service Provider" -url http://SharePointServer:9900 -mysiteurl http://mysite.SharePoint.pri:80 -indexserver SomeServer -indexlocation "d:\index" -ssplogin domain\SSPAccount -ssppassword Password -sspdatabasename Shared_Services -searchdatabasename SSP_Search_DB

So here are the parameter descriptions:

-title: the title of the SSP... Make this meaningful, as you may find in larger farms that multiple SSPs are needed for a variety of reasons.

-url: the url of the SSP, including the port. This is usually fine for oddball ports, as almost all functions of the SSP are server requests, not user requests, so users never see the url.

-mysiteurl: the url of your MySite Web App. This is needed for the profile and user linkage, as well as the personalization functions of the MySite Web App.

-indexserver: the server that will hold the crawl role for the SSP. This does not enable the crawl role, but sets the parameters. You must have the index/crawl role already configured as is noted above.

-indexlocation: the physical file location of the index files on the crawl server.

-ssplogin and -ssppassword: the user and password for the ssp identity.

-sspdatabasename: the name used for the SSP database. This is not the content DB of the Admin page for the SSP, that was specified in the Web App Extend command. This is the location of SSP configuration and data (like profile details).

-searchdatabasename: the name used for the index DB.

Once this phase is complete, you have a functional SSP. The only remaining steps to perform in the SSP that are not yet scriptable are the Profile Import to pull user profiles from a directory source (and schedule updates), and Search details. Search details include the content sources and crawl schedules. You'll actually find that those two functions are just about the only manual processes that need to be done in a fully scripted installation.

3rd: The Required Steps to Configure Outbound Email.

Outbound SMTP Email is one of the configuration settings that will give you the red "Your Farm is Broken!" warning, because outbound email is a fairly integrated part of MOSS. It is used in admin notifications, user notifications for task assignment, workflows, as well as user alert subscriptions.

Outbound email is configured via STSADM using the Email command.

stsadm.exe -o email -outsmtpserver mail.domain.pri -fromaddress SharePoint@domain.pri -replytoaddress noreply@domain.pri -codepage 65001

The parameters are described below:

-outstpserver: This is the address or Fully Qualified Domain Name (FQDN) of your organization's SMTP Relay server.

-fromaddress: This is the address that will be listed as the originator of all emails coming from SharePoint. You can actually set a Web App version of this, but this is the default.

-replytoaddress: This is the reply to address, which is usually a bogus address like no-reply, or leavemealone.

-codepage: This is the Character Set for email encoding. Most will be using UTF-8, which is 65001.

There are inbound email functions that can be set, but these are not currently scriptable, and also requires local SMTP server configuration on the server that will receive email. Inbound email is a choice that many are split on. There is some good functionality with it, but also some bugs and gotchas...

4th: The Required Steps to Configure Excel Calculation Services.

Excel Calculation Services (ECS) need to be started on at least one server in the farm to provide calculation and web rendering for Excel Workbooks. To enable ECS, use the STSADM ProvisionService command on the server that this role will be activated on:

stsadm.exe -o provisionservice -action start -servicetype "Microsoft.Office.Excel.Server.ExcelServerSharedWebService"

This one is very basic and straight forward, and only has two parameters, the action and the servicetype. The servicetype is the namespace of the service to start.

These steps will bring your MOSS farm out of the "Red" zone, and ready for use. There are still many other great scriptable functions that can add to your farm configuration automatically. In the next installment, I'll go over things like Alternate Access Mappings, Managed Paths, Attaching Content DBs, Deploying Features, and all sort of good stuff like that! Until next time...!

Automated Farm Installations, part 1

2008-09-15T13:30:00.001-06:00

All the issue of this have finally been created, so here is a shortcut list to get to all three issues:

Part 1: Farm Installation

Part 2: Basic Configuration

Part 3: Advanced Configuration and DR

So there have been a number of posts put out on the web about automating the installation of WSS and even MOSS for development desktops and test servers, but I haven't seen much written about production farms, so here's my 2 cents.

There is a huge gain waiting to be realized in repeatable, dependable process with automated installation. On major gain is in Disaster Recovery. Time saved in manual procedures vs. automated installation processes can be as high at 2x.

Recently, in an effort to clean up some residuals surrounding a number of farm changes that were not done correctly, as well as to test our DR plans, we flattened our entire farm down to bare metal, and rebuilt. In doing so, we found that we saved over 8 hours of recovery time vs. our dry runs with a manual process. Our process installed MOSS, configured the basic farm options, configured some advanced options we needed in our farm, recreated all Web Apps, and reattached all content DB's (which had already been restored from tape).

After executing this script, we only had two additional activities to perform which could not be scripted out-of-the-box: configuring and scheduling the SSP Profile Import, and configuring the content sources and crawl schedules.

So what steps are required for something like this? You're in luck, because I'm going to give it to you...

1st: Install MOSS. The easiest way to get this done is to have a local file source for installing the application on your server. I like to create an "install" source on a utility server that I copy to my servers, with the x64 (or i386 if you are still 32-bit) dir along with any utility apps (I always install Notepad++ and PowerShell on my servers for troubleshooting and configuration) and patches. You can also include custom SharePoint Solutions or WebPart Packs.

At the root of the x64/i386 folder, I create my script. I start with the installation. You need to make an XML document that dictates what your configuration will be. It looks something like this:

<?xml version="1.0" encoding="utf-8"?>
<Configuration>
    <Package Id="sts">
        <Setting Id="LAUNCHEDFROMSETUPSTS" Value="Yes" />
        <Setting Id="REBOOT" Value="ReallySuppress" />
        <Setting Id="SETUPTYPE" Value="CLEAN_INSTALL" />
    </Package>
    <Package Id="spswfe">
        <Setting Id="SETUPCALLED" Value="1" />
        <Setting Id="REBOOT" Value="ReallySuppress" />
        <Setting Id="OFFICESERVERPREMIUM" Value="1" />
    </Package>
    <Logging Type="Verbose" Path="c:\moss_logs" Template="Office Server Setup(*).log" />
    <Display Level="None" CompletionNotice="no" />
    <PIDKEY Value="Your Product ID Here" />
    <Setting Id="SERVERROLE" Value="APPLICATION" />
    <Setting Id="USINGUIINSTALLMODE" Value="0" />
</Configuration>

You obviously need to replace your PIDKEY with whatever your licensing number is. This is the XML required by a MOSS installation for an Application server. By changing the "ServerRole" key to "WFE" you can install a Web Front End server. You can also use the ServerRole of SINGLESERVER, but I recommend against this in most cases. Single Server setups can never be expanded at all. you're normally better off installing as APPLICATION, which includes the WFE and App (SSP/Admin) roles so you can add servers to the farm later. If you know it will never grow, then use SINGLESERVER.

You can script the installation with your xml like this:

SETUP.EXE /config MySettings.xml

This will give you the base MOSS files, without and system configuration.

2nd: System Configuration is done in a script using the PSCONFIG.EXE utility. There are a few commands that must be used, and they are as follows:

Configdb, HelpCollections, SecureResources, Services, InstallFeatures, AdminVS, and ApplicationContent.

In your install script, it make life much easier if you add a pth statement like this:

path %path%;"C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN"

...before you start in with PSCONFIG and STSADM commands. PSCONFIG will always have a "cmd" that dictates what part of the utility we are executing. The first PSCONFIG command, ConfigDB is the key command for either creating, or connecting to the config database for the farm. The command looks something like this:

psconfig -cmd configdb
-create
-server MyServerName\InstanceName
-database MOSSFarmConfigDBName
-user Domain\FarmAdmin
-password FarmAdminPassword
-admincontentdatabase MOSSCentralAdminContent

The key parameter's here are as follows:

Create: This is to make a new DB. To connect to an existing one, "Connect" would be used.

Server: This is the SQL Database Server that will hold the Config DB for the Farm. If it is a named instance, be sure to include the instance name.

Database: The name of the database to create or connect to. If creating, it must not exist currently.

User: The name of the farm admin account that will be used to connect to the ConfigDB. It needs to have permissions on the local server, as well as on the DB server.

Password: The password for the farm admin account.

AdminContentDatabase: The name of the admin content DB on the SQl server that houses the config DB.

There are other parameters, but these are the most commonly used. The AdminContentDatabase parameter is not needed on a "Connect", and the user and password are not needed on a create for a SINGLESERVER deployment, as Network Service is used for the farm admin account.

After running the ConfigDB command, a few other commands need to be issue to complete the system configuration:

psconfig -cmd helpcollections -installall
psconfig -cmd secureresources
psconfig -cmd services -install
psconfig -cmd installfeatures
psconfig -cmd adminvs -provision -port 5555
-windowsauthprovider onlyusentlm
psconfig -cmd applicationcontent -install

There is a parameter on the AdminVS command that is handy that I like to specify (it is optional)... The -port parameter. It allows you to specify which port the central admin app will live on. Obviously if this is not a server that will have central admin on it, you do not run this command.

Well, this ended up much longer than originally anticipated, but that is because I like to know "why", so I added some "why". Part two will be coming soon, and will include stuff like provisioning Shared Service Providers, and creating Web Applications... Until then...

Email Enabled List Alias Management

2008-08-15T15:07:00.001-06:00

Ever notice that there is not way to centrally manage or get information about email aliases? Oh that annoys me! So I did what any self respecting geek would do, and I started taking it apart... Here are a couple SQL utility scripts to help you get more out of your SharePoint! Standard Disclaimer - Don't mess around with the DB... You can break stuff! Now, here's the goods:

-- SQL Script to find out where an Email Alias is in use

-- Written by Josef Nielsen, 2008
-- nielsenjl_at_ldschurch.org
-- http://www.sharepointblogs.com/echef

-- Run this script against the Farm Configuration DB
SELECT [Alias], [Deleted], [SiteMap].[Path], [Objects].[Name], [ListId]
FROM [WSS_Farm_Config].[dbo].[EmailEnabledLists]
INNER JOIN [SiteMap] ON [EmailEnabledLists].[SiteId] = [SiteMap].[Id]
INNER JOIN [Objects] ON [SiteMap].[DatabaseId] = [Objects].[Id]
-- Change this value to the Alias you are looking for
WHERE [Alias] = 'MyEmailAlias' -- This is the Name part of Name@SharePoint.server.com

-- Run this script against the Content DB that the Site resides on
SELECT [tp_Title], [tp_ServerTemplate], [tp_ItemCount], [tp_Description], [tp_EmailInsertsFolder], [tp_EmailAlias], [tp_Fields], [tp_ContentTypes], [tp_DefaultWorkflowId]
FROM [WSS_ContentDB_01].[dbo].[AllLists]
--Replace the GUID Below with the GUId of the List you are looking for
WHERE [tp_Id] = 'A4BB3401-3161-430A-B330-42143C3DE879'

So, what do you get out of this? Well, the first script, run against your Config DB will give you the managed path and site collection name where that alias is in use. It will also tell you which content DB contains that site collection. It also gives you a GUID for the List.

In the second script, add the GUID you got for the list and run it against the Content DB that was also specified by the first script. This will give you the friendly name of the list that uses this alias, as well as a few other yummy bits of data about this list.

Enjoy!

Pre-populating Form Fields for a New Item

2008-08-15T15:06:00.001-06:00

So for surveys and such I thought it would be nice to pre-populate a SharePoint List "new" form with some data from the link... This makes it very nice for surveys and such from users. In this case it was to automate and remove error from some user feedback for our helpdesk. So what I did was make the URL contain an extra parameter for a field value, then I added some JavaScript to the NewItem.aspx page in that list. This script is specific to one field one (as you can tell by the long auto-ID). Here is the script I used:

    function getURLParam()
    {
        var strReturn = "null";
        var strHref = window.location.href;
        //find the "Ticket" parameter
        if ( strHref.indexOf("?") > -1 )
        {
            var strQueryString = strHref.substr(strHref.indexOf("?")+1);
            var aQueryString = strQueryString.split("&");
            for ( var iParam = 0; iParam < aQueryString.length; iParam++ )
            {

              //find the Task Parameter
              if (aQueryString[iParam].indexOf("Ticket=") > -1 )
              {
                var aParam = aQueryString[iParam].split("=");
                strReturn = aParam[1];
                break;
              }
            }

            //insert parameter to Task Field
            //This should be one line, not two...
            //the field name is too big to fit in the blog window ;)

document.aspnetForm.ctl00_m_g_2a4ef5db_f38c_4101_b1e9_bd5bce3e5a04_
    ctl00_ctl04_ctl01_ctl00_ctl00_ctl04_ctl00_ctl00_TextField.value = strReturn;
         }
    }
_spBodyOnLoadFunctionNames.push("getURLParam");

Notice the execute line, using _spBodyOnLoadFunctionNames. This is required to get the script to execute after all the content has been populated. The URL to feed this function would look something like this:

http://sharepointserver.company.pri/sites/feedback/lists/tickets/NewItem.aspx?Source=http%2A%2F%2Fsharepointserver%2Ecompany%2Epri%2Fsites%2Ffeedback%2FPages%2FThannkYou%2Easpx&Ticket=123456

Two things to note... first, the "Source" parameter needs to be Escaped (using "%" codes for all symbols), and second, that it doesn't have to be where you came from... It is actually where you go to when you click OK or Cancel. In this case, I'm sending the user to a Thank You page since they have filled out the feedback. This can be anything, including a custom page with code to close the browser window if you want.

Scripting the "Connect to Outlook" function

2008-08-15T15:05:00.001-06:00

You've got to love the "Actions, Connect to Outlook" function in SharePoint lists... Handy for offline viewing of data, nicer GUI for detail entry, etc. Wouldn't it be nice to automate the connection of these things for a team or a project, or even a division or company?

You can force these connections via script... They are URL based using the "stssync://" protocol, which depends on the Office WSS services, a shared component of the desktop Office Suite. You can find the specific call to connect a library to Outlook (much easier to let SharePoint format it that create from scratch) on any of the AllItems.aspx default list pages for a library or list that is "Outlook Friendly", including Tasks, Calendars, and Document Libraries. View your page source (on an IE browser, as this is not available in other browsers) and looking for the following:

<ie:menuitem id="zz23_OfflineButton"

There is a lot more to this element, which is jammed on a very long line containing about 6 of these <ie:menuitem> elements. Specifically out of this element you want to get the "onMenuClick" action, which is a javascript call to "ExportHailStorm". You will need a copy of this function in your script as well, as this is the function that creates the stssync call. It is located in the init.js file, located in 12\templates\layouts\1033 folder (for US versions)...

The call to ExportHailStorm should look something like the code below, although I've added line breaks to make it readable.

ExportHailStorm(
   'documents',
   'http:\u002f\u002fsharepoint.company.com\u002fteam\u002fsitename\u002fsandbox',
   '{ac5b6eaf-744a-4f73-a2e1-6e35b81f109e}',
   'Sandbox',
   'Test Files',
   '\u002fteam\u002fsitename\u002fsandbox\u002fTest\u002520Files',
   '','\u002fteam\u002fsitename\u002fsandbox\u002fTest Files');"

You can use these parameters with the MS code in init.js for ExportHailStorm to make your own script with multiple connections for Outlook. Each call to ExportHailStorm ends in a window.location.href call to the newly created link, which for a document library will look something like this:

stssync://sts/?ver=1.1&type=documents&cmd=add-folder&base-url=http:\u002f\u002fsharepoint.company.com\u002fteam\u002fsitename\u002fsandbox&list-url=\u002fteam\u002fsitename\u002fsandbox\u002fTest\u002520Files&guid={ac5b6eaf-744a-4f73-a2e1-6e35b81f109e}&list-name=Test\u520Files&site-name=Sandbox

These strings can be captured and put in to a simple vbscript or powershell script or even a bat file (run iexplore.exe <url>) and executed in a post setup command, a login script, or embedded in a web page on the intranet (ie, click here to connect standard outlook folders)...

Mutex Mischief

2008-08-15T14:42:00.001-06:00

To clean up an old farm from some setup errors, I recently rebuilt the farm from bare metal, re-attaching all the content DB's after the rebuild to prevent data loss. Imagine my horror when after 100% successful testing, and flawless installation, the first page I pull up shows this:

Mutex could not be created.

Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.
Exception Details: System.InvalidOperationException: Mutex could not be created.

After some research I learned that this is an ASP.Net issue that occasionally crops up when an app pool identity (ie the Web App Service Account in SharePoint) is not a local administrator. When setting the identity, access to the Windows Registry key where the IIS Mutex Key is kept is supposed to be granted (obviously not an issue for local admins). If it does not have access to read this key, the above error is generated. To add it, you have to modify the key and grant permissions for you identity account(s) to read that key, then close all Mutex Threads (or just reboot the server).

A big thanx to Jerry Orman who documented this issue and the fix here:

http://blogs.msdn.com/jorman/archive/2006/07/24/system-invalidoperationexception-mutex-could-not-be-created.aspx

As a side note to any trying to implement least-permission security on a locked down server, make sure your local WSS_WPG group has full control of the Windows\Temp folder, or you'll get an odd ASP.Net Temporary files error (that points to a bogus dir). The WSS_WPG group contains all your Web App Identity accounts, and is created by the SharePoint Installation.

Getting Search Crawl Details from the DB

2008-08-15T14:38:00.001-06:00

Ok, so I must be on a roll... Here's another glorious script that goes directly to the SharePoint DB's... Don't tell Bill! As usual, this is not recommended by MS, etc., etc., etc. This one is to get result sets of your Crawl Details. It will show each attempt to start/stop/delete a crawl, what it's current status is, when it was requested, started, and finished. Handy for monitoring your Search crawling with home grown tools ;)

--Begin Script

/*
CrawlLogDetails.sql
Written by
Josef Nielsen
Nov. 2007

Displays MOSS Crawl Details (Type, status, and times)
Point this script at your Search DB (ie. SharedServices_Search_DB)
*/

BEGIN

-- Create temp tables for System values
CREATE TABLE [#CrawlStatus](
[CrawlStatusName] VARCHAR(35),
[CrawlStatusID] INT
)

CREATE TABLE [#CrawlType](
[CrawlTypeName] VARCHAR(25),
[CrawlTypeID] INT
)

-- Populate Crawl Status System Values
INSERT INTO [#CrawlStatus] VALUES ('CRAWL_ACQUIRED', 1)
INSERT INTO [#CrawlStatus] VALUES ('CRAWL_STATUS_INSERTSTARTPAGE', 2)
INSERT INTO [#CrawlStatus] VALUES ('CRAWL_STARTCHECK', 3 )
INSERT INTO [#CrawlStatus] VALUES ('CRAWL_STATUS_START', 4)
INSERT INTO [#CrawlStatus] VALUES ('CRAWL_STATUS_FORBID', 5)
INSERT INTO [#CrawlStatus] VALUES ('CRAWL_UPDATE_SEED', 6 )
INSERT INTO [#CrawlStatus] VALUES ('CRAWL_QUERY_DONE', 7 )
INSERT INTO [#CrawlStatus] VALUES ('CRAWL_STATUS_DELETEUNVISITEDITEMS', 8 )
INSERT INTO [#CrawlStatus] VALUES ('CRAWL_STATUS_PAUSE', 9 )
INSERT INTO [#CrawlStatus] VALUES ('CRAWL_STATUS_RESUME', 10)
INSERT INTO [#CrawlStatus] VALUES ('CRAWL_STATUS_DONE', 11 )
INSERT INTO [#CrawlStatus] VALUES ('CRAWL_UPDATE_STOP', 12 )
INSERT INTO [#CrawlStatus] VALUES ('CRAWL_STATUS_STOP', 13 )
INSERT INTO [#CrawlStatus] VALUES ('CRAWL_STATUS_RESET', 14)
INSERT INTO [#CrawlStatus] VALUES ('CRAWL_START_DELETE', 15 )
INSERT INTO [#CrawlStatus] VALUES ('CRAWL_DELETE_CS', 16 )
INSERT INTO [#CrawlStatus] VALUES ('CRAWL_DELETE_SA', 17 )

-- Populate Crawl Type System Values
INSERT INTO [#CrawlType] VALUES ('CRAWLTYPE_FULL', 1 )
INSERT INTO [#CrawlType] VALUES ('CRAWLTYPE_INCREMENTAL', 2 )
INSERT INTO [#CrawlType] VALUES ('CRAWLTYPE_DELETE', 6 )

-- Join MSCrawlHistory to SCrawlHostList and our two temp tables
SELECT    [CrawlID]
        ,[HostName]
        ,[CrawlTypeName]
        ,[CrawlStatusName]
        ,[RequestTime]
        ,[StartTime]
        ,[EndTime]
FROM [SharedServices1_Search_DB].[dbo].[MSSCrawlHistory]
LEFT JOIN [dbo].[MSSCrawlHostList] ON [ProjectID] = [HostID]
LEFT JOIN [#CrawlStatus] ON [Status] = [CrawlStatusID]
LEFT JOIN [#CrawlType] ON [CrawlType] = [CrawlTypeID]
WHERE 1 = 1

-- Uncomment and use this conditional to filter the results to just one Web App
--AND [HostName] = 'MySharePointSiteName'
ORDER BY [RequestTime] DESC

END

-- Do a little clean up and get rid of those pesky temp tables
DROP TABLE [#CrawlStatus]
DROP TABLE [#CrawlType]

--End Script

Security Trimming WebControls and ASP Objects

2008-08-15T14:35:00.001-06:00

I hadn't used this yet, and had cause to this week. It works slick, and is pretty configurable... I used it to hide the SiteActions button on list pages for members, but not admins, as well as admin web parts embedded in a page. It works with Web Parts, Web Controls, and other ASP.Net objects (ie. SharePoint:*, etc.). Wrap the content you want trimmed in the following code (using SPD):

<Sharepoint:SPSecurityTrimmedControl runat="server" PermissionsString="BrowseDirectories">
[Content to Trim]
</Sharepoint:SPSecurityTrimmedControl>

You can then swap out the "BrowseDirectories" with whatever you need for the trimming. Here are the one's I've found handy so far:

BrowseDirectories = Anyone but Limited Read (Anonymous is Limited Read)
ManageWeb = Site Collection Admins
ManageSubwebs = Site Owners
AddListItems = Site Members and specified list contributors

Here's a link to all the defined values in the SPBasePermissions Enum.

Details and manual monitoring of the Content DBs

2008-08-15T14:34:00.001-06:00

So our Ad-Hoc environment started growing a bit faster than we had originally anticipated. We knew we would have some disparity between site's content size, so we set our content DB max site limits a bit lower than normal (hey, we have 50 of them, so we thought we'd be safe). The thought was that way we could help balance the sizing by adjusting the max counts on the DB's to reflect the physical size based on content.

It quickly became way to much of a pain to manually collate the size details with the site details based on content DB... So here's a little script I wrote up (ok, modified from my original Site Details script) that pulls all the goodness you could want about a content DB direct from the DB itself... <Insert canned warnings about how MS does not recommend querying the DB directly here>

/*
ContentDBReport.sql
written by Josef Nielsen
October 2007

NOTE: You must create a linked server if you use multiple SQL server to house you content DBs
*/

BEGIN
DECLARE @ts1 varchar(1000), @ConfigDB VARCHAR(128)

-- Set your Config DB Name here if it is different
SET @ConfigDB = 'SharePoint_Config'

-- This creates a temp table to hold the list of content DBs referenced by the Config DB
CREATE TABLE [#TempDbList]
(
DBname VARCHAR(128),
DBInstance VARCHAR(128),
DBServer VARCHAR(128),
MaxSites INT,
WarnSites INT
)

-- Populate the temp table with content DBs
SET @ts1 = 'INSERT INTO #TempDbList
SELECT [DbName].[Name] AS ''DatabaseName'',
[Instance].[Name] AS ''DatabaseInstance'',
[Server].[Name] AS ''DatabaseServer'',
CONVERT(XML, [DbName].[properties]).value (''(/object/sFld/text())[1]'', ''int'') AS ''MaxSites'',
CONVERT(XML, [DbName].[properties]).value (''(/object/sFld/text())[2]'', ''int'') AS ''WarnSites''
FROM '+'['+@ConfigDB+']'+'.[dbo].[Objects] AS [DbName]
LEFT JOIN '+'['+@ConfigDB+']'+'.[dbo].[Objects] AS [Instance]
ON [DbName].[ParentId] = [Instance].[ID]
LEFT JOIN '+'['+@ConfigDB+']'+'.[dbo].[Objects] AS [Server]
ON [Instance].[ParentId] = [Server].[Id]
WHERE [DbName].[Properties] LIKE ''%SPContentDatabase%''
AND [DbName].[Properties] NOT LIKE ''%WebApplication%'''

EXEC (@ts1)

DECLARE @ts2 VARCHAR(1000)

--This creates a temp table to hold the end results of the Site Collection lists from all Content DBs
CREATE TABLE [#TempContentDbList]
(
WebApp VARCHAR(128),
DBServer VARCHAR(128),
DBName VARCHAR(128),
DBSites int,
DBWarnSites int,
DBMaxSites int,
DBSize float
)

-- Create a cursor to walk through each content DB
DECLARE DB_cursor CURSOR
FOR
SELECT [DBServer], [DBInstance], [DBName], [MaxSites], [WarnSites]
FROM [#TempDbList]

OPEN DB_Cursor

-- Declare Variables to populate by Cursor
DECLARE @vDBServer VARCHAR(128)
DECLARE @vDBInstance VARCHAR(128)
DECLARE @vDBName VARCHAR(128)
DECLARE @vMaxSites INT
DECLARE @vWarnSites INT
DECLARE @DBv1 VARCHAR(5000)

FETCH NEXT FROM DB_cursor INTO @vDBServer, @vDBInstance, @vDBName, @vMaxSites, @vWarnSites
WHILE @@FETCH_STATUS = 0
BEGIN

-- Add a backslash for DBServers that are not default instances
DECLARE @slash VARCHAR(5)
IF @vDBInstance = ''
SET @slash = ''
ELSE
SET @slash = '\'

-- Script to insert Content DB details to the temp site summery table
SET @DBv1 = 'INSERT INTO [#TempContentDbList]
SELECT [ConfigObjects].[Name] AS ''WebApp'',
(SELECT ''' + @vDBServer+@slash+@vDBInstance + ''') AS ''SQL Server'',
(SELECT ''' + @vDBName + ''') AS ''Content DB Name'',
(SELECT COUNT([Webs].[Title])) AS ''Current Site Count'',
(SELECT ' + CONVERT(VARCHAR(20), @vMaxSites) + ') AS ''Max Site Count'',
(SELECT ' + CONVERT(VARCHAR(50),@vWarnSites) + ') AS ''Site Size'',
(SELECT round(sum(convert(float,[size])*8/1024),2) AS ''DB Size in MB''
FROM
[sys].[master_files]
WHERE
[state] = 0
AND [data_space_id] = 1
AND db_name([database_id]) = ''' + @vDBName + '''
GROUP BY [database_id]) AS ''Site Size''
FROM
['+@vDBServer+@slash+@vDBInstance+'].['+@vDBName+'].[dbo].[sites] AS [Sites] WITH (NOLOCK)
LEFT JOIN ['+@vDBServer+@slash+@vDBInstance+'].['+@vDBName+'].[dbo].[webs] AS [Webs] WITH (NOLOCK) ON [Webs].[siteID] = [Sites].[Id]
LEFT JOIN '+'['+@ConfigDB+']'+'.[dbo].[SiteMap] AS [ConfigSiteMap] WITH (NOLOCK) ON [ConfigSiteMap].[Id] = [Sites].[Id]
LEFT JOIN '+'['+@ConfigDB+']'+'.[dbo].[Objects] AS [ConfigObjects] WITH (NOLOCK) ON [ConfigSiteMap].[ApplicationID] = [ConfigObjects].[Id]
WHERE
[Webs].[ParentWebId] IS NULL
GROUP BY [ConfigObjects].[Name]'

EXEC (@DBv1)

FETCH NEXT FROM DB_cursor INTO @vDBServer, @vDBInstance, @vDBName, @vMaxSites, @vWarnSites

END

CLOSE DB_cursor
DEALLOCATE DB_Cursor

END

-- Cursor is closed and released, and now we select the results of the scan
SELECT * FROM #TempContentDbList ORDER BY [WebApp], [DBName]

-- Clean up to get rid of those temp tables
DROP TABLE [#TempDbList]
DROP TABLE [#TempContentDbList]

Pulling site collections details via direct SQL query

2008-08-15T14:32:00.001-06:00

I certainly don't recommend making changes to your content DBs directly in SQL, but there's no harm to be had pulling data from the DB's. I found that this was the easiest way to poll data about all farm content DBs and Web Apps listed by Site Collection. Hope you find this useful!

SiteReport.sql

written by Josef Nielsen

September 2007

NOTE: You must create a linked server if you use multiple SQL server to house you content DBs

BEGIN

DECLARE @ts1 varchar(1000), @ConfigDB VARCHAR(128)

-- Set your Config DB Name here if it is different

SET @ConfigDB = 'SharePoint_Config'

-- This creates a temp table to hold the list of content DBs referenced by the Config DB

CREATE TABLE [#TempDbList]

(

DBname VARCHAR(128),

DBInstance VARCHAR(128),

DBServer VARCHAR(128)

)

-- Populate the temp table with content DBs

SET @ts1 = 'INSERT INTO #TempDbList

SELECT [DbName].[Name] AS ''DatabaseName'',

[Instance].[Name] AS ''DatabaseInstance'',

[Server].[Name] AS ''DatabaseServer''

FROM '+'['+@ConfigDB+']'+'.[dbo].[Objects] AS [DbName]

LEFT JOIN '+'['+@ConfigDB+']'+'.[dbo].[Objects] AS [Instance]

ON [DbName].[ParentId] = [Instance].[ID]

LEFT JOIN '+'['+@ConfigDB+']'+'.[dbo].[Objects] AS [Server]

ON [Instance].[ParentId] = [Server].[Id]

WHERE [DbName].[Properties] LIKE ''%SPContentDatabase%''

AND [DbName].[Properties] NOT LIKE ''%WebApplication%'''

EXEC (@ts1)

DECLARE @ts2 VARCHAR(1000)

--This creates a temp table to hold the end results of the Site Collection lists from all Content DBs

CREATE TABLE [#TempSiteList]

(

FullURL VARCHAR(128),

WebApp VARCHAR(128),

DBServer VARCHAR(128),

DBName VARCHAR(128),

Megs BIGINT,

Quotamax VARCHAR(128),

Quotawarning VARCHAR(128),

Userquota VARCHAR(128),

Siteowner VARCHAR(128),

OwnerEmail VARCHAR(128),

Sitecreationdate VARCHAR(128),

Lastcontentchange VARCHAR(128)

)

-- Create a cursor to walk through each content DB

DECLARE DB_cursor CURSOR

FOR

SELECT [DBServer], [DBInstance], [DBName]

FROM [#TempDbList]

OPEN DB_Cursor

DECLARE @vDBServer VARCHAR(128)

DECLARE @vDBInstance VARCHAR(128)

DECLARE @vDBName VARCHAR(128)

FETCH NEXT FROM DB_cursor INTO @vDBServer, @vDBInstance, @vDBName

WHILE @@FETCH_STATUS = 0

BEGIN

DECLARE @DBv1 VARCHAR(2000)

-- Add a backslash for DBServers that are not default instances

DECLARE @slash VARCHAR(128)

IF @vDBInstance = ''

SET @slash = ''

ELSE

SET @slash = '\'

-- Script to insert Site Collection details to the temp site summery table

SET @DBv1 = 'INSERT INTO [#TempSiteList]

SELECT [Webs].[FullUrl],

[ConfigObjects].[Name] AS ''WebApp'',

(SELECT ''' + @vDBServer+@slash+@vDBInstance + ''') AS ''SQL Server'',

(SELECT ''' + @vDBName + ''') AS ''Content DB Name'',

(([Sites].[diskused])/1024)/1024 AS ''Megs'',

(([Sites].[diskquota])/1024)/1024 AS ''Quota max'',

(([Sites].[diskwarning])/1024)/1024 AS ''Quota warning'',

(([Sites].[userquota])/1024)/1024 AS ''User Quota'',

[User].[tp_login] AS ''Site Owner'',

[User].[tp_email] AS ''Owner E-mail'',

CAST([Sites].[timecreated] AS char(30)) AS ''Site Creation Date'',

CAST([Sites].[lastcontentchange] AS char(30)) AS ''Last Content Change''

FROM

['+@vDBServer+@slash+@vDBInstance+'].['+@vDBName+'].[dbo].[sites] AS [Sites] WITH (NOLOCK)

LEFT JOIN ['+@vDBServer+@slash+@vDBInstance+'].['+@vDBName+'].[dbo].[webs] AS [Webs] WITH (NOLOCK) ON [Webs].[siteID] = [Sites].[Id]

LEFT JOIN ['+@vDBServer+@slash+@vDBInstance+'].['+@vDBName+'].[dbo].[userinfo] AS [User] WITH (NOLOCK) ON [User].[tp_SiteID] = [Sites].[Id]

LEFT JOIN '+'['+@ConfigDB+']'+'.[dbo].[SiteMap] AS [ConfigSiteMap] WITH (NOLOCK) ON [ConfigSiteMap].[Id] = [Sites].[Id]

LEFT JOIN '+'['+@ConfigDB+']'+'.[dbo].[Objects] AS [ConfigObjects] WITH (NOLOCK) ON [ConfigSiteMap].[ApplicationID] = [ConfigObjects].[Id]

WHERE

[Webs].[ParentWebId] IS NULL

--AND [User].[tp_SiteID] = [Sites].[Id]

AND [User].[tp_SiteAdmin] = 1

AND [User].[tp_id] = 1'

EXEC (@DBv1)

FETCH NEXT FROM DB_cursor INTO @vDBServer, @vDBInstance, @vDBName

END

CLOSE DB_cursor

DEALLOCATE DB_Cursor

END

-- Cursor is closed and released, ad now we select the results of the scan

SELECT * FROM #TempSiteList ORDER BY [WebApp], [FullURL]

-- Clean up to get rid of those temp tables

DROP TABLE [#TempDbList]

DROP TABLE [#TempSiteList]

Background on My SharePoint Links

2008-08-15T14:30:00.001-06:00

So recently we had some issues that came up around the "My SharePoint Links" option that exists on default master pages under the menu option "My Links". Our issue was that a few sites never showed up on that list for some people during testing. This spawned a number of questions about this process, which I decided to share, as I couldn't find much on the Internet currently about this. This is the information I've found, seen, and some is my best guess, based on the behavior of the system.

When My SharePoint Sites shows up

My SharePoint Links only shows up when you have multiple Site Collections. If you are working with one Site Collection, the list item for these links will not appear. After adding another collection, there is a waiting/polling period before it appears. This seems to be 5-30 minutes usually. My best guess is that this is linked to an sptimer job, although I haven't found information on that yet. This appears to be the same job that "converts" a new site to standard security objects (see below).

Which Sites show up on the My SharePoint Sites list

So which sites belong on that list? Any site for which the current logged in user is in the configured "Members" group. Owners, Admins, and Visitors make no difference for this list, only Members. This is the same list that is populated on MySites in the profile section labeled "Memberships". You can manage these at http://<mysite_root_url>/_layouts/MyMemberships.aspx...

How security is setup originally

As far as I've been able to tell, any given site, when created, contains a custom list for security that is not linked to actual security objects. It does seem to link to AD security principles (the "Account" field), but the rest on the information is just standard editable fields (see screen shot below).

You can get to this first screen by adding _layouts/people.aspx to your site address (It's the people section of People and Groups), then select settings, list settings.

This second screen is accessed by just clicking on the user's name or image in a security group or the All Users screen.

After a 5 to 30 minutes time period (this seems to be about the same time period - and perhaps the same sptimer job? - as updates to your MySite "About Me" section, which appears in the user info screen), the security information is updated, and looks like the screen shots below.

Notice that there are only two columns listed (above), and all the fields in the User Information (below) are now read-only.

At the time when this change happens, the site will now appear on the My SharePoint Sites list. My belief is that this conversion process changes the security table to a series of objects that are now readable by SharePoint's core system as security, rather than a list. The My SharePoint Links object calls a security lookup that cannot read from those unconverted sites, only from converted ones.

When things break...

So what exactly was the problem we were seeing then? Based on the above information, I found that the few sites we had that never populated on the My SharePoint Links list all still had that "new site" security list that had not yet been converted. The sites had been created days ago, in a few cases over a month ago, but the sites never changed.

This led me to alter my belief about this possible sptimer job. The behavior makes me believe that there is a "convert flag" somewhere in the site information that tells SharePoint if it is a new site, or a converted site. This (possibly fictional) sptimer job only converts sites where the flag has not yet been set, and it sets this flag after the conversion.

How to fix it when "things break"...

Unfortunately, my call to MS Premiere ended up being a bit more of an educational session for them, and I still do not have a reasonable answer to this issue, although the issue is still open and they are researching this behavior now. I did find that I could easily use my MOSS backup solution, AvePoint's DocAve, to backup content and restore it to a new site that had been converted, but this still leaves the question of how to fix a site without a 3rd party tool and a bunch of delete/recreate operations. I'm still waiting for that answer, but now I think I understand how this part of SharePoint functions a bit better. I'll post the answer (if there is one) whenever I get it...

SQL 2005 Embedded Edition... What the heck is that?

2008-08-15T14:29:00.001-06:00

So I ran in to a copy of SQL 2005 Embedded today... first time I've seen it. It was on a MOSS install that some folks were testing, and they wanted the content moved over to our Production environment. No Problem, says I... I went to go make a backup of the Context DB to import in to the Production farm to move the content, but I couldn't connect to the DB server with my Management Studio.

Scratching my head with a perplexed look on my face, I loaded the Management Studio on the local server and tried opening it up there. No Dice... Apparently, it is an IP disabled version that only allow local named pipes connections, or something.

The only way I found to connect to the thing was by telling the Management Studio to connect to \\.\pipe\mssql$microsoft##ssee\sql\query

Not very intuitive... but it works...

Those dang System Screens...

2008-08-15T14:28:00.001-06:00

If you've ever looked at the URL for an of the _catalog or _layouts admin pages, you may have thought like I did, "I can remember that... It's just xxx.aspx in the layouts folder"... Yeah right... We've taken, like many people do, and hidden some of the menu options in the Site Settings screen, to help our users not mess with things they do not understand in the Self-Provisioned Team Sites we have. Now if only I can remember which ones I hid and how to get to them... :)

Here's a list I made up to help me remember:

People and Groups	_layouts/people.aspx	Users and Permissions
Site Collection Admins	_layouts/mngsiteadmin.aspx	Users and Permissions
Advanced Permissions	_layouts/user.aspx	Users and Permissions
Master Pages	_Layouts/ChangeSiteMasterPage.aspx	Look and Feel
Title, Desc, and Icon	_layouts/prjsetng.aspx	Look and Feel
Navigation	_layouts/AreaNavigationSettings.aspx	Look and Feel
Page Layout and Ste Templates	_Layouts/AreaTemplateSettings.aspx	Look and Feel
Welcome Page	_Layouts/AreaWelcomePage.aspx	Look and Feel
Tree View	_layouts/navoptions.aspx	Look and Feel
Top Nav Bar	_layouts/topnav.aspx	Look and Feel
Site Theme	_layouts/themeweb.aspx	Look and Feel
Reset to Site Definition	_layouts/reghost.aspx	Look and Feel
Searchable Columns	_Layouts/NoCrawlSettings.aspx	Look and Feel
Site Content Types	_layouts/mngctype.aspx	Galleries
Site Columns	_layouts/mngfield.aspx	Galleries
Site Templates	_catalogs/wt/Forms/Common.aspx	Galleries
List Templates	_catalogs/lt/Forms/AllItems.aspx	Galleries
Web Parts	_catalogs/wp/Forms/AllItems.aspx	Galleries
Workflows	_layouts/wrkmng.aspx	Galleries
Master Pages and Page Layouts	_catalogs/masterpage/Forms/AllItems.aspx	Galleries
Regoinal Settings	_layouts/regionalsetng.aspx	Site Administration
Site Libraries and Lists	_layouts/mcontent.aspx	Site Administration
Site Usage Report	_layouts/usageDetails.aspx	Site Administration
User Alerts	_layouts/sitesubs.aspx	Site Administration
RSS	_layouts/siterss.aspx	Site Administration
Search Visability	_layouts/srchvis.aspx	Site Administration
Sites and Workspaces	_layouts/mngsubwebs.aspx	Site Administration
Site Features	_layouts/ManageFeatures.aspx	Site Administration
Delete This Site	_layouts/deleteweb.aspx	Site Administration
Site Output Cache	_Layouts/areacachesettings.aspx	Site Administration
Content and Structure	_Layouts/sitemanager.aspx	Site Administration
Content and Structure Logs	_Layouts/SiteManager.aspx?lro=all	Site Administration
Search Settings	_layouts/enhancedSearch.aspx	Site Collection Administration
Search Scopes	_layouts/viewscopes.aspx?mode=site	Site Collection Administration
Search Keywords	_layouts/listkeywords.aspx	Site Collection Administration
Recycle Bin	_layouts/AdminRecycleBin.aspx	Site Collection Administration
Site Collection Features	_layouts/ManageFeatures.aspx?Scope=Site	Site Collection Administration
Site Hierachy	_layouts/vsubwebs.aspx	Site Collection Administration
Portal Site Connection	_layouts/portal.aspx	Site Collection Administration
Site Collection Audit Settings	_layouts/AuditSettings.aspx	Site Collection Administration
Site Collection Policies	_layouts/Policylist.aspx	Site Collection Administration
Site Collection Cache Profiles	Cache%20Profiles/AllItems.aspx	Site Collection Administration
Site Collection Output Cache	_Layouts/sitecachesettings.aspx	Site Collection Administration
Site Collection Object Cache	_Layouts/objectcachesettings.aspx	Site Collection Administration
Variations	_Layouts/VariationSettings.aspx	Site Collection Administration
Variation Labels	_Layouts/VariationLabels.aspx	Site Collection Administration
Translatable Columns	_Layouts/TranslatableSettings.aspx	Site Collection Administration
Variation Logs	_Layouts/VariationLogs.aspx	Site Collection Administration
Site Settings	_layouts/settings.aspx	Other

Allowing NetBIOS responses on a DNS Alias in Win 2K3

2008-08-15T14:27:00.001-06:00

You must disable "Strict Name Checking" on Windows 2003 server to allow the server to respond to a DNS alias. This is done via registry editing:

HKLM\System\CurrentControlSet\Services\LanmanServer\Parameters
Value name: DisableStrictNameChecking
Data type: REG_DWORD
Radix: Decimal
Value: 1

This allows the Server "Server1" or "Server1.MyDomain.Pri" to respond to a DNS entry like "CoolService" or "CoolService.MyDomain.Pri"... This is disabled by default, as it loosens security. It is not recommended to do this in a DMZ or Internet Zone.

FYI, a reboot is required to make the change work.

The new eChef!

2008-08-15T14:23:00.001-06:00

New and improved, eChef 2.0! Extra thanx to all the SharePoint Expert's guys for hosting me for the last year or so... I'm going to replicate a couple of the more popular posts from the past here, then on to the new stuff...!