Latest Posts
When installing Team Foundation Server 2008 using an existing MOSS deployment we ran into the following error:
TFS2200401: The specified Windows SharePoint Services site URL (http://server) is not the default site collection site: (). The default site collection site might have been renamed or removed. Make sure that the site exists and verify the correct URL, and then attempt installation. If the problem persists, you can choose to install and configure Windows SharePoint Services as part of the Team Foundation Server installation process.
I looked at the install log file: dd_install_vstf_at_90.txt and found:
wsschecker.exe : Another site already exists at http://server. Delete this site before attempting to create a new site with the same URL, choose a new URL, or create a new inclusion at the path you originally specified.
I tried a few different things with no luck.
Resolution:
In the end I created a new site collection (interesting the existing site collection was at http://server and not http://server/sites/x). When I created the new site collection I was given the default http://server/sites/ option and filled in a new URL. TFS installed fine from there.
Now we have to integrate the TFS site collection into the client's existing site collection or migrate their old site collection to the new one. J
I've seen a lot written about this particular issue. We just ran across this yesterday and here is how I solved it.
Symptoms:
Logging in to the MOSS/WSS Central Administration web site works fine from the local machine (MOSS central admin server) but when logging in from remote machines an NTLM prompt is presented and domain admin, domain farm admin, etc. accounts are "not authorized". The typical behavior of the NTLM prompt coming up three times before the error page (401.1) is displayed.
However, I found that if I logged in as the local machine administrator (of the MOSS server) it worked fine. For example DOMAIN\Administrator fails but SERVERNAME\Administrator works.
Troubleshooting:
It was clear to me that this was an authentication problem and had nothing to do with MOSS. To test my theory I created a simple web site in IIS and turned off anonymous access. Then I tried connecting to that site remotely and it worked. I had actually expected it to fail. Next I set my test web site to use the same application pool as central admin. This time my test site behaved the same as central admin. The common thread here is Kerberos authentication was not working when run using the central admin app pool user account.
I ran SetSPN (you can download this from www.Microsoft.com/downloads if you don't have it) –L domain\moss central admin account (in this case domain\MOSS_CA). Sure enough there were no entries.
Resolution:
Run SetSPN –A http/server.domain.local domain\MOSS_CA (remember that you need to substitute your server, domain and account).
Next open Active Directory Users and Computers (with access to your domain's AD) and find the domain\MOSS_CA account (whatever your central admin app pool is running under) and open properties. Click on the Delegation tab and choose "Trust this user/computer for delegation to any service (Kerberos)".
At this point I had to reset the password on the service(s) using the account and update the account's permissions in SQL Server. Then I rebooted and everything was working properly.
If you need additional information (i.e. more details about where to find your Central Admin app pool account, etc.) leave a comment and I'll do my best to get back to you.
Ugh, what a crappy bug. I have a fully licensed RTM version of MOSS 2007 running on my Virtual Server. I have been playing about with changing Master Pages quite successfully. Actually I think that is a great feature and I am longing to show it off to a client. However, when I went to the Page Settings page and tried to change the Page Layout from one to another I got this error:
After a bit of Googling, I discovered that this is a case of bad error message. To cut a long story short it comes down to a DCOM permissions bug. To fix it I had to add my MOSS app's IIS Application Pool domain account to the local BUILTIN\Administrators user group and then it all worked just fine.
So much for least privilege, although I guess I can change it back afterwards! :s
Technorati Tags:
MOSS 2007,
Sharepoint
I had a weird problem a while back where the history bar for IE7 on my Windows Vista Ultimate box was not showing anything at all - not even the dates. This was not like I had cleared the history, rather it was more like it was not loading it in the first place. As you can see below, not that the menu did not even have the sort options in it:
Since a large part of the functionality both Windows Explorer and Internet Explorer comes from shell extensions that are loaded through COM classes, I took a look at the folder where the history should be stored. In my case this was at:
C:\Users\<username>\AppData\Local\Microsoft\Windows\History
Now the way Explorer (and IE7) determine which shell extensions to load is by looking in a hidden file called "desktop.ini". You may need to turn on hidden system file to be able to see it if it is not there. To do that:
- Click the round blue Start thing in the left corner
- Click on Computer
- Click on the Organize button on the toolbar and chose Folder and Search Options
- Click the View tab
- Click Show hidden files and folders
- If you want to see system files as well (which we do here) unclick "Hide protected operating system files (Recommended)"
- Click OK
Now open the desktop.ini file in Notepad (usually double-clicking it will invoke Notepad) and ensure that it contains the following:
[.ShellClassInfo]
ConfirmFileOp=0
DefaultToFS=0
CLSID={FF393560-C2A7-11CF-BFF4-444553540000}
UICLSID={7BD29E00-76C1-11CF-9DD0-00A0C9034933}
If not, paste it in and save it. Now log off and on again and open IE7.
Hopefully your history is now back - it worked for me anyway. :)
Mark
Just found this great tip from Steven Tapping on how to suppress this annoying message that Vista Remote Desktop app always pops up:
Remote Desktop cannot verify the identity of the computer you want to connect to.
Here is the link: http://blogs.vertigo.com/personal/steventap/Blog/Lists/Posts/Post.aspx?ID=3
Setting up a Microsoft Dynamics CRM 3.0 system where the laptop clients are running Windows Vista and Microsoft Office Outlook 2007 I attempted to install the laptop client from the CRM_VC3_CLIENT.iso which is for Vista and Outlook 2007 (get it here). NOTE: this is for "on premise" for service providers there is a different ISO.
The error I got (see below) is:
The type initialize for
"Microsoft.Crm.Setup.Common.CommonResource" threw an
exception.
File or assembly name Microsoft.Crm, or one of its dependencies, was
not found.
The first problem was easily fixed:
The System Requirements screen said that the Indexing Service was not installed – this is used for backward compatibility in Vista. To resolve I opened Appwiz.cpl and installed the Indexing Service.
No big deal. To ensure everything was clean I did a reboot. Then I ran setup again and got this:
I did a Google search and came up empty (except for others asking how to fix it). So here's the fix:
Disable and stop the Indexing Service
- Open services.msc
- Open the Indexing Service properties page
- Set it to disabled and stop it
- Click Apply
- Run the CRM client setup again. This time you will get back to the System Requirements screen and see the following:
- Leave setup open and go back to services and set Indexing Service to automatic and start it (note: you must click Apply after setting it to Automatic before you can start it).
- Lastly, go back to the CRM setup System Requirements dialog and click Back and then Next and finish your install.
Hope this helps
I just tried downloading and installing the Orcas Beta 1 Virtual PC version. It unpacks two VHDs and a couple of VMC files. While there are instructions for how to load these in Virtual PC, they do not work for Virtual Server. It seems there is some trickery involved in getting this to work on Virtual Server 2005 that I might have spent hours looking for had it not been for a very useful post by Jason Nadrowski. In his post Setting up Visual Studio Code Name "Orcas" Beta 1 Team Suite (Virtual PC version) the pertinent part that I needed was this:
What isn't described in the instructions but perhaps should is how to link this base VHD to OrcasBeta1VSTS.vhd in Virtual Server. From the Virtual Server Left Nav, go to Virtual Disks group and then select Inspect. Select the Orcas VHD in the drop down and then click the Inspect button. This page allows you to modify the parent virtual hard disk(s) and therefore specify any path for the Base01.vhd.
Thanks Jason. Very helpful. What a wonderfully obscure setting to have to find.
One interesting thing that I noticed was that the path to the base VHD was called "TimeBombedBase". Hmm... :)
I hit a weird bug today when trying to install Longhorn Server Beta 3 on a new box I just built for that purpose. I put in a Highpoint RocketRaid 2310 RAID controller set up with three 500GB SATA drives in RAID5 on an Intel D945GTP motherboard.
I booted up the PC into the Longhorn DVD and started the installation process. As expected once I got to the drive selection screen nothing showed up. I inserted my USB Flash drive with the Highpoint RAID controller driver on it and chose Load Driver. Then from there I navigated to the flash drive and to the drivers I copied to it. After choosing the right driver for my setup, the Longhorn setup now found my RAID drive. However, when I clicked on Next, instead of moving to the next screen, I was greeted with a wonderful error:
Windows is unable to find a system volume that meets its criteria for installation
Nice! Well to cut a long story short, after a bunch of fiddling around it turns out that in order to get past this to install Longhorn Server you have to go back into your BIOS, change the hard drive to be the first drive and first device in the boot order (so move it before the DVD drive and/or any LAN cards) and try running setup again.
On the second time around, do exactly the same as the first time, insert the flash drive, load the driver and then select the newly discovered RAID drive. This time around hitting Next will take you to the next installation screen and you should be good to go. Weird, huh?
After this week's security updates installed themselves and kindly rebooted our server (yes we normally turn these off but this one got through), we discovered that our internal Microsoft Office SharePoint Server 2007 was no longer working.
After narrowing the problem down to Security Update for Microsoft .NET Framework 2.0 (KB928365), we determined that somewhere along the line SharePoint was not loading properly. IIS was happily serving up basic HTML pages, but when we tried to hit even the Sharepoint Central Administration page, all we got was a 404 error. The Event Log normally has some sign that something is wrong, it may not give you the detail but at least it mentions something. However, in this case there was nothing at all other than Search Crawler failures.
Just as we were starting to think we were going to have to go down the usual, install/re-install, fiddle with some settings then install again route, on a whim I decided to check the Web Service Extension settings in IIS Manager. As it happens I was rewarded with a surprisingly simple fix. It turns out that something in the 7/10/2007 security update patch process managed to disable ASP.NET v2.0.50727 – exactly the thing that MOSS needs to work. So, just the click of one button set everything right as we were back up and running again.
I love security. :-S
For anyone else that has hit this problem just go to IIS Manager:
Click on "ASP.NET v2.0.50727" in the right-hand pane, and click the Allow button. All you should see is the status changing as below.
That's it. Now go hit that Sharepoint URL again and you should be rewarded with success.
If that worked for you then I'm glad I could help. If not, I'm sorry but that's the wonderful world of security updates for you...
Recently I spent way more time that I should have diagnosing my main machine that became unbootable right after uninstalling Acronis Migrate Easy 7.0. I had bought a new hard drive and decided to try using the tool to do a clone of my old drive onto the new one. It appeared to do a fantastic job and initially I was very happy with the result. That is, until I uninstalled the Acronis software and did a reboot…
My machine became unbootable. Every time I booted the machine it got itself in a reboot loop, never getting past the first part of the loading screen. Of course I tried the obvious – hit F8, pulled up the boot menu and selected Safe Mode boot. This helped in as far as I could see each driver it was loading, but as soon as it got to crcdisk.sys it blue-screened on me and that was it.
At this point I was pretty mad but not panicking too much as I knew that the Vista DVD came with a new tool called the Windows Recovery Environment (WinRE). It is designed to automatically detect and repair a bunch of the most common boot problems without any user interaction. I have used it before on a hard drive that became unbootable and it worked wonderfully. Not this time however.
After running the tool and waiting for quite a while for it to do full disk test it failed to fix the problem. So I ran up the command prompt off the WinRE menu and did some digging of my own. The boot settings seemed to be fine – if you want to verify, use bcdedit to check and fix the new Vista boot configurations.
To cut a long story a little shorter, I finally came around to checking the file system filter drivers to see if anything was getting in the way of the file system loading up. As it turned out, this was the culprit. There was an upper filter driver that was still trying to load up that had not been properly cleaned up by the Acronis Uninstall. There was still an entry that was trying to load the driver file snapman.sys but the file was not there anymore. On boot, Windows reads the filter driver entries in the registry and looks for the corresponding driver file, if it is not there, Windows will not be able to load.
Now that we know where to look, the fix is easy:
- Insert your Windows Vista DVD and boot up to the DVD boot menu.
- Press OK to get past the language settings.
- Choose Repair Computer.
- Choose cancel if asked to run System Restore
- At the menu, choose Command Prompt. This will put you on a command line in the WinRE.
- Enter "regedit" without the quotes.
- Highlight HKEY_LOCAL_MACHINE (HKLM) in the left pane.
- Go to the File menu and choose Load Hive.
- In the source box, navigate to the drive where Vista is installed (C: in my case). Drill down to C:\Windows\System32\Config. Choose the "System" file (with no extension). Hit OK.
- In the next window name the hive "Broken System" without the quotes.
- Hit the plus next to HKLM. You will see a key named " Broken System".
- Drill down to HKLM\Broken System\ControlSet001\Control\Class\{4D36E967-E325-11CE-BFC1-08002BE10318}.
- Look in the right pane for an Upper Filters line. If you see "snapman" without the quotes, you need to delete it.
- Only delete snapman by using the Modify on the Edit menu entry. Make sure you do not delete any other Upper Filters in the list.
- You should also check HKLM\Remote System\ControlSet001\Control\Class\{71A27CDD-812A-11D0-BEC7-08002BE2092F} for Upper Filter entries. If you see "snapman" remove it from there as well.
- Now unload the Remote System hive. Highlight it in the left pane. Go to the File menu and choose Unload Hive. This will save the changes in the Vista registry.
- Exit the command prompt and hit Restart
- Keep your fingers crossed…
In my case this solved my problem and I was finally able to boot Vista without having to resort to a rebuild. Your mileage may vary… good luck!!!
After doing some Google searching, it seems it is not obvious to a lot of people how to remove the HDD password on a Toshiba laptop, specifically in my case the Toshiba M400 Tablet PC. The only option in the BIOS setup screen appears to be to reset the password with no apparent way to remove it. As it turns out the solution is incredibly simple:
- Open the BIOS setup menu
- Go down to the HDD password
- Type your current HDD password and press Enter
- Now press Enter twice at the requests for the new password and confirm new password
- Press END and Y
That's it. Password cleared.
I spent a large part of my day today building a Windows Server 2003 virtual machine with Visual Studio 2005 set up so that I could do some MOSS 2007 development on the road. During the set up process I went through my usual steps of installing Visual Studio 2005 followed by installing the monolithic Visual Studio 2005 Service Pack 1. However this time around things did not go as expected.
Every time I ran the SP1 install it came up with the following error:
Product: Microsoft Visual Studio 2005 Team Suite - ENU -- Error 1718.File C:\WINDOWS\Installer\4a1fef.msp did not pass the digital signature check. For more information about a possible resolution for this problem, see http://go.microsoft.com/fwlink/?LinkId=73863. |
Now since the dialog box did not contain a hyperlink, I did the usual moan and groan and tried again, ignoring the link in the text. Seems this was a stupid thing to do as, for once, the error message was actually almost useful. Clicking on the link takes you to http://support.microsoft.com/kb/925336 which tells you that all you need to do is install this hot-fix KB925336 for Windows Server 2003 and all will be well.
Sure enough, installing that did indeed fix the problem. Next time I will try the link first on the off-change it sends me somewhere helpful…
I have been using the build in Validator controls that come with ASP.NET and have found them very useful. I especially like the regular expression validator as it works as a great backup when there is nothing else available. However the need came up for me to validate a couple of date text fields that I was using with the new AJAX Toolkit Calendar Control. The control is awesome for providing a quick and simple drop-down date picker with almost no extra coding. However it does not validate that the date in the text box is a valid date format. As it turns out, there is a really easy way to do this with the CompareValidator control. Here is how I did this…
1. Before adding the date picker control, you must ensure the AJAX Toolkit is registered. Add this line at the top of the page right after the @Page directive:
<%@
Register
Assembly="AjaxControlToolkit"
Namespace="AjaxControlToolkit"
TagPrefix="ajaxToolkit"
%>
2. If you have not already done so anywhere else (such as your master page), you also need to add a ScriptManager to the page.
<asp:ScriptManager
ID="ScriptManager1"
runat="server"></asp:ScriptManager>
3. In the ASPX page add the following controls to give you a date picker with a drop-down graphic 
that displays the calendar control when clicked:
<asp:Label
ID="lblDate"
runat="server"
Text="Date: "></asp:Label>
<asp:TextBox
ID="txtDate"
runat="server"
Width="140px"></asp:TextBox>
<asp:Image
ID="imgCalendar"
runat="server"
ImageUrl="~/Images/Calendar.png"
/>
<ajaxToolkit:CalendarExtender
ID="CalendarExtender1"
runat="server"
TargetControlID="txtDate"
Format="MM/dd/yyyy"
PopupButtonID="imgCalendar"
/>
4. Now to ensure that the date entered in the text box is a valid parse-able date, simply add this one extra control to the page:
<asp:CompareValidator
ID="CompareValidator1"
runat="server"
ControlToValidate="txtDate" ErrorMessage="* Enter a valid date"
Operator="DataTypeCheck"
Type="Date"
ValidationGroup="grpDate" />
Make sure you set the Operator attribute to DataTypeCheck and the Type to Date and when you click on whatever button you have on your page that triggers a postback, the validator will try to parse the date into a DateTime and display the message if that fails. Of course, you also need to ensure that your button (or whatever) has CausesValidation set to true (the default) or the Validator will not trigger.
That's it! You now have a very cool drop-down date picker with validation and all with no coding involved.
This is a general error but here's where I ran across it.
On a network running SBS 2K3 R2 we were troubleshooting use of IPv6. We had it working on another server and one thing we did was compare installed updates. On the functioning server an update named "Windows Small Business Server 2003 R2" was listed. So we reinstalled the R2 technologies on the non-working server.
Then came the problems, first RPC via HTTP stopped working. After finding that RPC was disabled and enabling it (did not fix the issue) the Active Sync issue appeared.
The solutions was to enable Integrated Windows authentication on the exchange-oma virtual directory.
- Open IIS
- expand to Web Sites\Default Web Site
- right-click exchange-oma and choose properties
- click the Directory Security tab
- click the Edit button in Authentication and access control
- check the Integrated Windows authentication box
- click OK twice
On Windows XP SP2 I have run across this error a few times. Typically it is an unhandled exception in C:\Windows\msiexec.exe when trying to open Outlook for the first time. Detect and Repair Outlook (or other Microsoft Office applications returns the same error. No Office Updates will install.
I never determined the exact cause of the error but the following steps solved it.
- Download all versions of the .NET framework from www.microsoft.com/downloads
(at the time this post was written they were 1.0, 1.1, 2.0 and 3.0)
- Install 1.0 then 1.1 then 2.0 then 3.0 - each time choosing reinstall or repair.
- Reboot the machine
- Repair Outlook or Office
- Install Windows Updates and Office Updates (optional but recommended)
- Test
I believe this is corruption in the .NET framework somewhere along the way that breaks the C++Runtime Library.
Here are the downloads:
1.0 http://www.microsoft.com/downloads/details.aspx?FamilyID=d7158dee-a83f-4e21-b05a-009d06457787&DisplayLang=en
1.1 http://www.microsoft.com/downloads/details.aspx?FamilyID=262d25e3-f589-4842-8157-034d1e7cf3a3&DisplayLang=en
2.0 http://www.microsoft.com/downloads/details.aspx?FamilyID=0856eacb-4362-4b0d-8edd-aab15c5e04f5&DisplayLang=en
3.0 http://www.microsoft.com/downloads/details.aspx?FamilyID=10cc340b-f857-4a14-83f5-25634c3bf043&DisplayLang=en
OK, so it has been a while since I have had my head down in some code but this one caught me off guard for a while.
I have two pages: default.aspx and report.aspx. On default.aspx I have a form with a couple of drop-downs and a Proceed button that performs a cross-page post-back to the report.aspx page. In the report.aspx page I then wanted to get at the controls in the previous page (i.e. default.aspx) to retrieve the selected indexes from the form. Following the documentation on MSDN, I used the PreviousPage property to get a reference to the source page and then tried to use FindControl to get a reference to the controls on the default.aspx page. However, while this did compile, it didn't actually find the controls from the source page.
From the MSDN documentation:
if (Page.PreviousPage != null)
{
TextBox SourceTextBox = (TextBox)Page.PreviousPage.FindControl("TextBox1");
if (SourceTextBox != null)
{
Label1.Text = SourceTextBox.Text;
}
}
The version from my code:
if (Page.PreviousPage != null)
{
DropDownList drpEntity = (DropDownList)Page.PreviousPage.FindControl("drpEntity");
DropDownList drpDate = (DropDownList)Page.PreviousPage.FindControl("drpDate");
if (drpDate != null && drpEntity != null)
{ ...
It turns out that since I am using Master Pages, this example does not apply. The Master Page contains a ContentPlaceHolder control which the content of my page is embedded in, I needed to get a reference to that first and then do the FindControl within the ContentPlaceHolder control.
if (Page.PreviousPage != null)
{
ContentPlaceHolder cph1 = (ContentPlaceHolder)Page.PreviousPage.FindControl("contentplaceholder1");
if (cph1 != null)
{
DropDownList drpEntity = (DropDownList)cph1.FindControl("drpEntity");
DropDownList drpDate = (DropDownList)cph1.FindControl("drpDate");
if (drpDate != null && drpEntity != null)
{ ...
This worked well enough, but now I wanted to go one step further. If you are sure that the only way to this page is from the previous one (default.aspx in my case) as a cross-page post-back or a server transfer you can get the cast the PreviousPage object to the actual class for that page, and reference the properties directly.
First you need to put a reference for the previous page's namespace in your page's ASPX file right under the <%@
Page
<%@
PreviousPageType
VirtualPath="~/default.aspx"
%>
Now you need to expose the properties that you want to get to. Unfortunately the controls are not marked as public so directly referencing them will get you an "inaccessible due to its protection level" error. Instead just expose some public properties on the page that return the values you need. So in my Default.aspx:
public
partial
class
DefaultAspx : System.Web.UI.Page
{
public
string StartDate
{
get { return FormatMyDate(drpDate.SelectedIndex); }
}
public
string EndDate
{
get { return FormatMyDate(drpDate.SelectedIndex+1); }
}
public
string Entity
{
get { return drpEntity.SelectedValue; }
}
And that is it. Now you can get the PreviousPage property, cast it as the previous page's type and directly access the public properties you exposed in the previous code block.
if (Page.PreviousPage != null && PreviousPage is
DefaultAspx)
{
if (Page.PreviousPage.IsCrossPagePostBack == true)
{
string sStart = ((DefaultAspx)PreviousPage).StartDate;
string sEnd = ((DefaultAspx)PreviousPage).EndDate;
string entity = ((DefaultAspx)PreviousPage).Entity;
Works perfectly. Hopefully that helps at least one person out of a jam.
Mark
Today I kept getting a really strange error when I was trying to write some ASP.NET code. I am using a cross-page post-back and was having trouble getting the cast to work, casting the PreviousPage property to my previous page's type as in this line:
string sStart = ((DefaultAspx)PreviousPage).StartDate;
The error I was getting was:
The type 'DefaultAspx' exists in both '{guid}' and '{guid}'
This didn't make a whole lot of sense to me as it was not being referenced anywhere else. I tried a bunch of different things but finally narrowed it down to the files in my VS web cache. After deleting the files in cache folder the error magically disappeared. So for anyone who stumbles across this post, try deleting the files in:
c:\Users\<username>\AppData\Local\Microsoft\WebsiteCache\<websitename>
and
c:\Users\<username>\AppData\Local\Temp\Temporary ASP.NET Files\<websitename>
…and let me know if that worked for you too.
Yet another bunch of time spent on things that shouldn't be.
Just took a look at the log file folder for my company's MOSS 2007 server and found that the log file folder was taking up
33GB of disk space. In one day the log files added up to over 17GB! Now I am all for information but really, what were the SharePoint guys thinking? Oh, did I mention, this is a test server which was not even being used by anyone other than me at the time?
Now I did check the docs on MSDN. They state:
If you do not want to use the usage analysis features, you can turn off the usage analysis log to conserve hard-disk space (although the log files themselves are not large). If you decide that you do want to use these features, you can turn the log processing on again. Note that each time the log file is processed, the data is appended to the original log. If you want to conserve disk space, you should turn off usage analysis before it has been run the first time. This option is available only on the Microsoft Windows platform.
Some understatement! So as I said in the title, if you find yourselves running out of disk space on your MOSS server, check out
C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\LOGS
Obviously changing drives/file locations as appropriate.
Hope that helps…
When you setup an FTP server on a Windows Server 2003 system you may run into this issue if you are using RRAS and have configured the server as an Application Server (which causes the Application Layer Gateway service to start). There is a known issue with FTP and this configuration for downloading large files. However this can also affect an FTP server where "Allow anonymous connections" has been disabled.
To solve this you must configure the Application Layer Gateway (ALG) service to not make port mappings for your FTP server.
Here is the fix:
- On the server open Regedit
- Navigate to HKLM\Software\Microsoft\ALG\ISV
- Change the value of {6E590D61-F6BC-4dad-AC21-7DC40D304059} to Disable NOTE: not Disabled.
An IISReset is not required.
The Microsoft KB related to the large file download issue is here: http://support.microsoft.com/kb/931130/en-us
Thanks to Mark for setting up blogs for our company.
This seems amazingly simple. Once you know the trick (and there is a trick) blogging from Word 2007 to my blogging tool of choice – Subtext – is incredibly simple. Just click the Publish button on the toolbar and away you go. The trick is that you need to configure it like so:
First Click Manage Accounts and choose New (or if this is your first time Word will get here for you), then:
Replace the Blog Post URL with http://your_blog_url_here/services/metablogapi.aspx and then click on Picture Options.
Now for the tricky part. There is a known bug in Word 2007 that prevents pictures from being successfully uploaded with the default options. Until the bug is fixed the workaround relies on you having some sort of access to the folder where the pictures are stored. In my case I am lucky enough to have access using a UNC path to the folder location directly on the server. If I didn't I would have set up some sort of ftp folder or an HTTP upload site. As it is, with the UNC path of the server folder, I can persuade Word to upload the embedded files to the right location, like so:
Hopefully that helps at least one other poor soul struggling with this problem.
Now, with that out of the way… start blogging!