STS v3 beta 2 now avialable for public download

W00t!  Installing SPS as part of project server was more than a bit messy. now has STSv3 available as an independent download.  I am installing it right now (I feel like a kid in a candy shop…)


Sharepoint Services v3

In addition to looking at Project Server 2007 (which looks overly complicated… and still required IE for full-featured web access… bleagh!), I have been eyeballing STS3, the next version of Sharepoint.

Very Cool!

Here are some first impressions/highlights:

  • Default template for Blogs and Wikis
  • The Wiki resembles MediaWiki (it uses the same [[link]] syntax.  The Blog looks much like any other Blog, but with the in-line posting and editing features that make Sharepoint so easy to use.  The addition of Single sign-on and Directory Services integration make the service even easier to manage.
  • Directory lookup tool for groups and users (you no longer need to know the NetID or department group name)
  • Incoming mail support (errgh… this is going to get ugly… people will want this feature and it does not appear to work without Exchange!)
  • Installing Project Server 2007, Beta 2

    I have brought up a new test server to give Project Server 2007 a whirl. Here are some of the gotchas in the install process:

    • Install required "Windows Workflow Foundation, Beta2". I downloaded v2.2 from here:
    • Also required is ASP.NET 2.0, which is installed with the .NET Framework 2.0 components (available on Microsoft Update, or as a standalone installer. Apparently my .NET 2.0 was damaged, so I ran a repair install. After ensuring that ASP.NET was enabled in IIS, the Project Server installer now runs without complaint.
    • Project Server has an "all in one box" installation option. This installs and configures Sharepoint Services 3.0 and SQL 2005 Express Edition. It works surprisingly well!

    Also note that the test server performing miserably.  I have expanded the VM memory to 1Gb, and performed the following steps to expand the virtual drive:

    •  execute: vmware-vdiskmanager -x 15Gb <Path to.vmdk file>
    • Boot to BartPE CD with Paragon Partition Manager, expanded system drive.

    Ximage success

    I finally was able to generate an image of my Win2k3 VMWare reference system using Ximage (soon to be renamed “ImageX”).

    In the past I had many problems, although not strictly related to the utility itself:

    • Networking in VMWare workstation for the WinPE 2.0 beta in the Vista AIK will not function! Apparently this is a driver issue. There is a bug registered in the Vista beta program, but I never did follow up on it.
    • Networking in WinPE 1.5 did work, roughly speaking, but getting it all to function was like pulling teeth. WinPE 1.x kinda bites (not very user friendly)
    • BartPE networking works great! Unfortunately, getting the “C:” drive to mount on my VMware Workstation instance was a bit more difficult. Some forum hopping revealed that others who attempt to use Server 2003 SP1 as the source for the WinPE build also have this problem. By changing the source to Server 2003 RTM, I am now able to mount the C: drive, and thus run XImage.exe.

    XImage throughput was comperable to Ghost 8, and achieved almost identical compression ratios. CLI syntax is pretty straightforward. I think we have a winner…

    WinSSHD software deployment – scripted

    The Catalyst team asked me to evaluate and install an SSH/SFTP/SCP service for them on all of the CATXXX Windows servers. After some evaluation and testing, we settled on bitvise WinSSHD. To “save time” I decided to try scripting the install.

    Here is the process that I came up with:

    for /f %%s in (catserv.txt) do copy /v /y c:installWinSSHD-Inst.exe \%%sc$installWinSSHD-Inst.exe
    for /f %%s in (catserv.txt) do copy /v /y c:installcat_config.wst \%%sc$installcat_config.wst
    c:localbinpsexec.exe @catserv.txt "c:installWinSSHD-Inst.exe" -site=WinSSHD -acceptEULA -activationCode=[insertCodeHere] -settings=c:installcat_config.wst
    for /f %%s in (catserv.txt) do sc \%%s start winsshd
    for /f %%s in (catserv.txt) do sc \%%s query winsshd | find /i "running" >> isrunning.txt

    Note that this script required a few files to be in place before execution:

    1. Sysinternals “psexec.exe” must be in place in “c:localbin”.
    2. The WinSSHD installer must be located in “c:install”
    3. A WinSSHD server configuraiton file named “cat_config.wat” must be in place in “c:install”
    4. This script and the catserv.txt file must be present in “c:localscripts”. The catserv.txt file contains a simple list of the servers to which WinSSHD will be installed.

    Redirecting HTTP to HTTPS, part DUH.

    It always helps to know what you are doing…

    After much head bashing and tooth gnashing, I discovered that the real reason that most people recommending a solution to this problem present a client-side redirect is pretty simple:

    When browsers swith from a http:// rooted URI to a https:// rooted URI, they effectively assume that they are switching to a new website (which, effectively, they are).

    So, I implemented a client-side redirect by replacing the default “https required” IIS 403.4 error page with a custom page containing this javascript code:

    function goElseWhere()

    var oldURL = window.location.hostname + window.location.pathname;

    var newURL = "https://" + oldURL;

    query = '' + window.location;
    position = query.indexOf('?');
    if (position > -1)
    query = query.substring(position + 1);
    newURL = newURL + "?" + query;

    window.location = newURL;


    // end hide -->

    Unfortunately, this still does not work for MS Office programs. Office refuses to recognize a redirect request (be it either server or client based), so anyone attempting a manual save to an http:// rooted URI will just get an error. Nothing to be done for it... it is an office bug. Report it to the Office team, it is not my fault.