Thursday, May 31, 2007
Once or twice we've talked at work about how we'd like the ability to reorder programs (buttons) on the taskbar, and for a while now I've been running a small utility at home called Taskbar Shuffle that allows you to do just that. While it might not be quite ready to challenge Jeff Han's multi-touch work or Microsoft Surface, it does fill one of those "I'm surprised it's not in Windows" holes and is worth a look. (It works great on my XP box and although Vista isn't officially supported, some folk report that it runs under the 32-bit version albeit with some graphical glitches.)
P.S. If you download and get use from a piece of free software, don't forget to either register it or make a donation to help your fellow developer.
Sunday, May 27, 2007
While putting together my last post I ran across a strange problem where the first page access after an iisreset was taking more than 30 seconds to load. At its best, this always takes about twice as long as you'd like but this was unworkable. Worse still the same delay happened each time I used stsadm.exe or any other application that loads the SharePoint DLL.
After a reasonable amount of time troubleshooting this I was fast running out of ideas, and desperate enough to reach for Ethereal. Thankfully, it was there I found the answer to my problem. Each delay was accompanied by outbound requests to http://crl.microsoft.com or http://crl.verisign.com that from behind our proxy were going nowhere fast and taking a long while to timeout. (In this case, CRL stands for Client Revocation List, and I assume it is been checked to ensure the validity of the digitally signed SharePoint assemblies as they are loaded into the IIS process.)
The solution for my situation then, was as simple as specifying the correct proxy using proxycfg.exe. From a command prompt, you'd do something like this:
Update 27/06/2007: You need to modify this command to exclude local addresses to prevent MOSS crawls failing, as they too respect this setting. You can exclude all local addresses (those that don't contain a dot) as follows:
Alternatively, you can exclude specific URLs:
See the proxycfg.exe documentation for further details.
This workaround is good enough to get me going again. However, I'm no expert on certificate infrastructure so leave me a comment if I've missed something or got something wrong.
Hope this helps.
Monday, May 21, 2007
A while back, I posted about creating a cloneable SharePoint development machine. Although the method I described works well enough, you're somewhat limited by the fact that it requires you to install SharePoint in Standalone mode. This is workable for some scenarios, but the performance of SQL Server Embedded Edition (which Standalone mode uses) doesn't seem all that great, and by not running a full version of SQL you're missing out on the profiler and Reporting Services integration etc. Additionally, you're stuck running everything on one box with nowhere to go if you want to add additional virtual servers to test other topologies.
For these reasons, I've spent some time making Sysprep work with a Complete, rather than Standalone install of MOSS. If you've not done so already, now would probably be a good time to go back and read my previous post as I'll just point out the differences here to avoid duplication.
- If you're updating an existing Standalone install you need to uninstall SharePoint. You'll also want to manually uninstall SSEE.
- Install a full version of SQL Server 2005 with SP2. I'm using the developer edition configured to use Windows authentication and run as Local System. (I'm happy with this, although you might want to follow the principal of least privilege and use a less powerful account.)
- (Re)Install SharePoint, and from the Advanced screen select Web Front End if you're using WSS, or Complete if you're using MOSS. As before, do not run the SharePoint Products and Technologies Configuration Wizard after the install.
- Create a local account for use as a SharePoint service account. You don't need to assign any specific permissions to the account at this point, this will happen when we call psconfig.exe from our configuration script. Update: If you intend to set-up custom profile import mappings read this follow-up post.
- From the zip file linked at the bottom of this post, extract mossconfig2.bat into c:\Scripts. (You will still need the files from the previous post.) You also need to modify c:\Sysprep\sysprep.inf to call this new script, which now takes 4 parameters:
Since this script runs after the first logon following Sysprep we can assume that the current user is the intended site owner and build the first two parameters from environment variables. The last two parameters are the username and password of the service account we created earlier. The script requires the service account username to be prefixed with the computer name, which is again achieved using environment variables. See sample.inf included in the download for an example of how to call this from Sysprep.
Once you've made these changes you can take a snapshot of the machine and run Sysprep to reseal to machine.
The trick to making this work is the significantly updated configuration script that automates the work which normally happens when you run the SharePoint Products and Technologies Configuration Wizard. It looks like this:
1: @echo off
2:
3: psconfig -cmd configdb -create -server %COMPUTERNAME% -database SharePoint_Config -user %3 -password %4
4: if not errorlevel 0 goto errhnd
5: psconfig -cmd helpcollections -installall
6: if not errorlevel 0 goto errhnd
7: psconfig -cmd secureresources
8: if not errorlevel 0 goto errhnd
9: psconfig -cmd services -install
10: if not errorlevel 0 goto errhnd
11: psconfig -cmd installfeatures
12: if not errorlevel 0 goto errhnd
13: psconfig -cmd adminvs -provision -port 8000 -windowsauthprovider onlyusentlm
14: if not errorlevel 0 goto errhnd
15: psconfig -cmd applicationcontent -install
16:
17: :SetupServices
18: REM *** Moss Only ***
19: REM echo Starting search
20: stsadm -o osearch -action start -role indexquery -farmcontactemail %2 -farmserviceaccount %3 -farmservicepassword %4 -defaultindexlocation "C:\Program Files\Microsoft Office Servers\12.0\Data\Applications"
21: if not errorlevel 0 goto errhnd
22:
23: :CreateSSP
24: REM *** Moss Only ***
25: REM echo Creating webapps for SSP
26: stsadm -o extendvs -url http://%COMPUTERNAME%:8010 -ownerlogin %1 -owneremail %2 -exclusivelyusentlm -apidname "SSP - 8010" -apcreatenew -apidtype configurableid -apidlogin %3 -apidpwd %4
27: if not errorlevel 0 goto errhnd
28: stsadm -o extendvs -url http://%COMPUTERNAME%:8020 -ownerlogin %1 -owneremail %2 -exclusivelyusentlm -apidname "My Sites - 8020" -apcreatenew -apidtype configurableid -apidlogin %3 -apidpwd %4
29: if not errorlevel 0 goto errhnd
30:
31: REM *** Moss Only ***
32: REM echo Creating SSP
33: stsadm -o createssp -title "Shared Service Provider" -url http://%COMPUTERNAME%:8010 -mysiteurl http://%COMPUTERNAME%:8020 -indexserver %COMPUTERNAME% -indexlocation "%Programfiles%\Microsoft Office Servers\12.0\Data\Applications" -ssplogin %3 -ssppassword %4
34: if not errorlevel 0 goto errhnd
35:
36: :CreateSiteCollection
37: REM For WSS select a suitable site template e.g. STS
38: REM echo Creating site collection
39: stsadm -o extendvs -url http://%COMPUTERNAME%:80 -ownerlogin %1 -owneremail %2 -exclusivelyusentlm -apidname "SharePoint - 80" -sitetemplate BLANKINTERNETCONTAINER -apidtype configurableid -apidlogin %3 -apidpwd %4
40: if not errorlevel 0 goto errhnd
41:
42: iisreset
43: "C:\Scripts\wssdebug.exe" http://localhost /enable
44: goto end
45:
46: :usage
47: REM echo Usage
48: REM echo mossconfig2.bat OwnerLogin OwnerEmail ServiceAccount ServiceAccountPassword
49: REM echo\
50: REM goto end
51:
52: :errhnd
53: :end
54: pause
This is heavily based on Jukka Paajanen's How to create a web application from the command line article, with some modifications for running in this context. Once it's finished, you'll have the following setup:
- A site collection built with the Publishing Portal template that ships with MOSS running on port 80.
- Central Administration running on port 8000.
- A Shared Service Provider running on port 8010.
- A separate web application for hosting My Sites running on port 8020.
If you're using WSS you'll need to make a couple of modifications. You don't have the Shared Service Provider, My Sites or search to configure so comment out lines 21, 27, 29 and 34. In addition, change the site template parameter supplied to stsadm.exe (line 40) from BLANKINTERNETCONTAINER to STS to have the site collection use the Team Site template. Have a look in C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\1033\XML at WEBTEMP.xml (and also at WEBTEMPSPS.xml if you're using MOSS) to see all of the available templates and their names for use with this parameter.
It's worth pointing out that there is nothing in the script to perform any configuration on SQL 2005. Despite the machine having its SID replaced and its name changed SQL just keeps on working, although I don't know if this would be the case if you were to use SQL 2000. Having said that, SQL does store the machine's name internally, and the steps you need to follow to update it could easily be automated if required. Incidentally, if you need to rename a machine that is already running SharePoint check out the new 'renameserver' stsadm.exe operation.
It's less than ideal having this spread over two posts, but hopefully it's clear enough for you to get what you came here for. If not, feel free to let me know in the comments where I'll try and answer any questions.
WssSysprep2.zip
Wednesday, May 09, 2007
I recently found myself wondering how many times a day I click the mouse. A quick Google turned up a few promising tools, but none of them were really what I had in mind. As a big fan of keyboard shortcuts, I wanted to know not only how many times I click the mouse but also how many times I click the mouse per application, the idea being that I could use this to figure out which application's shortcuts might be worth learning. With this in mind, I present Clickr. Here's what it does:
- Counts the total number of left, right and middle (wheel) mouse clicks.
- For each click logs either the description of the executable (default) or window title of the current foreground window. (Logging the description makes the most sense I think. Run two instances of Clickr and log both if you like.)
- Displays the total clicks, clicks per window and the date and time logging began on a Windows Form.
- Minimizes to the notification area (system tray).
Most of this was put together using standard .NET 2.0 Windows Forms stuff. The key to making it work was the fact that you can use .NET to set a low level hook to monitor mouse events, and from there it only takes a little more Win32 work to get a handle to the foreground window and ultimately the window title or executable description. Once I had this working, I added a couple of optimizations to firstly cache the descriptions (which are too expensive to fetch for every click) and secondly ensure that I'm not trying to update the form when it's minimized, as this is also fairly expensive and clearly not very sensible.
I'm not sure anyone else will find this particularly useful but I had fun putting it together and so I thought I'd share it here. There's a link to the executable at the bottom of this post, and although it's not exactly production quality I'll put the source code up as well. It should run on Vista and XP (with the .NET 2.0 Framework) but I've not tested it beyond running it on my machine for a few days, so you mileage may very well vary.
Clickr_1_0.zip
Clickr_Source_1_0.zip