The White Pages – Page 44 – Random musings and thoughts on Power BI, Microsoft 365, Business Intelligence, and occasionally even diving from John White

Second Foundation Intelligence is now UnlimitedViz

Published March 3, 2011

You may have noticed a change to the header of this blog. My company, Second Foundation Intelligence is in the process of a name change to UnlimitedViz. This is being done to better distinguish what we do with SharePoint and Business Intelligence from the ERP focused activities of our sister company, Second Foundation Consulting.

Operationally, nothing changes, and this change will be gradual. The new address for this blog will be http://whitepages.bifocal.show (which works now) but http://whitepages.second-foundation.com will continue to work for the foreseeable future.

You can read the press release announcing this change here

Wakatobi Dive Resort, As Good As It Gets

Published March 1, 2011

This is one of those occasional diving related posts. If you’ve been following this blog, you’ll notice that it’s been pretty quiet for the past little while. That’s because been lucky enough to have been in Indonesia at the Wakatobi Dive resort, and blogging was pretty far from my mind. I just got home a few days ago, and what an incredible experience.

Wakatobi is well hyped. This can be very risky for an attraction. I had extremely high expectations going in, and they were all exceeded.

Wakatobi Dive resort is located just off the island of Tomia, in South East Sulawesi, in Indonesia. It’s a bit of a haul. My experience (from Toronto) was that it took about 25 hours of travelling to get to Bali, overnight in Bali, and then another 2.5 hour charter flight to Wakatobi.

It’s worth every minute.

I was too tired on arrival in Bali to really see much of it, but if you have the time, it’s quite an amazing place. I did get to spend a day on the way back with a pretty incredible tour guide, Komang Wardiapa, owner of Bali-Go-Round Tours. If you’re in Bali for any reason, I highly suggest that you contact them – it will be well worth your while.

Once at Wakatobi, I was escorted to my own cabin by one of the many Wakatobi dive guides, and was given the ins and outs of the stay at the resort, including where my personal storage for my dive gear was on land, on the boat, my allocated area in the dedicated camera room, and the dive site schedule for my stay. I should mention that once my luggage was tagged by the greeter at the Bali airport, I never needed to touch it again until I was unpacking in my room.

Wakatobi operates a fleet of six 70 foot custom built dive boats. While I was there, they were operating three for 35 guests. If you’re counting, that’s fewer than 12 divers per 70 foot dive boat, and there were at least 2 dive guides per boat. This was extremely comfortable boat diving. Of course, if the boat diving is too much, you can dive the best house reef in the world anytime you wish.

The instructors, like all the rest of the staff were extremely helpful, and highly professional. Their focus was on the diver, but they never let safety get ignored. I had requested to use Nitrox during my stay, and was asked for my certification card. I’ve NEVER needed to produce that card before, so I stopped carrying it, and didn’t have it with me. It was quite clear that they’d need to see proof of certification before proceeding, (which I very much appreciate) but no problem, they went ahead and contacted the agency and got the requisite proof with no further input on my part.

I could go on and on about the facilities, the staff, and the way that they run their operation. Their web site, as nice as it is, doesn’t even do it proper justice. I was made aware (by Komang, mentioned above) of the fact that they were recently featured on a dive travel show, “Into the Drink”. if interested, you can watch the entire show here, it’s about 20 minutes long. I was struck by how the hosts impressions mirrored my own, both of Bali and of the resort.

I had a nice plus in that I had the opportunity to attend the Ikelite Photo School, put together by Frank Owens and Steve Miller (no, not that Steve Miller…). As you can see from previous posts on my blog, I have had some experience with underwater photography, but with just a couple of days of instruction (over drinks in most cases!), and I was quickly able to produce images like those below. I’ll let you be the judge of how successful it was.

(Top to Bottom: False Clown Anemonefish, Hairy Squat Lobster, Colman’s Pygmy Seahorse (about 2mm), Blue Ribbon Eel, and Willan’s Chromodoris Nudibranch)

You can view the entire gallery on Flickr here

Steve and Frank will be offering the school again this summer – I highly recommend it. If you’re interested in other dates, I know that they’d be happy to consider them – you can contact them via the links on the school’s page.

I’m still buzzing from this trip. It has quite literally been the trip of a lifetime, and the best dive resort that I’ve ever seen. I’m already plotting how to get back there.

It’s now back to work for me. I should have an interesting announcement posted here shortly.

Using Document Templates with Lists and Content Types in SharePoint

Published February 8, 2011

While the concept of document templates has been in SharePoint for a very long time, and content types since SharePoint 2007, I often find that many organizations don’t take complete advantage of their power, or don’t use them at all. In many cases, this is because they are unaware of how to properly do so.

This post is an attempt at demonstrating how templates can work with both libraries and document templates, taking full advantage of the metadata contained within SharePoint in the document. It will also describe an approach that we use to help with their maintenance.

I have described 3 walkthrough scenarios, each complete in its own right, but when taken together form a comprehensive template management strategy. These 3 scenarios are:

Using a Library Template
Using a Content Type Template
Use A Library to Manage Your Document Templates

All of the examples here are shown using the 2010 suite of tools (Office 2010, SharePoint 2010). However, almost all of this capability is available in the 2007 family of products. Some of the menu locations are different with 2007 (Particularly with Word) , but the capabilities are there.

A – Using a Library Template

The simplest way of working with templates is to modify the default template for a document library. In the example below, we’ll create a new library, create metadata, display and use the metadata, and finally, create a new document based on this template. Several of the steps used in this example will be used in the other examples.

1. Create a new Document library

From your destination site, click either “Libraries” or “All site content” from the Quick Action pane on the left (note – the menu options that appear will vary according to the site template used, and the options that have been chosen by the site administrator). If neither option is available, select “Site Actions” then View All Site Content”.

Finally, from the resultant dialog, select “Document Library”, give the new library a name, and click the “Create” button. In this case, we’ll use “Letters”.

2. Add metadata to the library

Now we need to add some metadata to this library. When the Library is first created, the Library ribbon tab will be open. From there click the “Library Settings” button.

On the following screen, in the columns section, select “Create Column” (or add from existing site columns, and add the metadata fields that you want to use with this library. In this case, we’ll add a few (pretty boring) fields that you might want to use when tracking letters.

Side note – as a best practice, I try to never use spaces in the names when creating fields, lists, sites, etc. When spaces are used, SharePoint converts these spaces to _x0020_ in the internal field names. Once the field is created, the name can be changed, and that will only affect the display name, not the internal field name.

3. Edit the default template

Once we have our metadata fields in place, it is time to edit the default template. This example is using a word template, but the same approach works for other Office content (Excel, Powerpoint, etc).

Without leaving the list settings screen, select Advanced Settings (in the General Settings section).

On the next screen, there is a section for the library’s document template. in that section, select the “(Edit Template)” link. Word should open (you may be prompted for credentials) and then you will be editing the library template.

4. Show the Document Information Panel

Since we want to incorporate the document metadata into the body of the document, we will want to use the document information panel. The document information panel will show the user editable metadata for a document. When the document is stored in a SharePoint library, or is a template for one, you can also expose the metadata from the library itself (or from a content type….more on that later). The nice part is that it can be displayed right at the top of the document, so if the properties are used throughout the document, you only need to edit them in one place. Unfortunately, it is turned off by default, and it really has to be one of the best hidden features in Word 2010. It was hard enough to find in 2007 – you had to add the developer tab to your ribbon, and then select “show information panel” there. In 2010, it’s hidden in the backstage.

Click File, and then click on the info tab. To the right of the screen you’ll see the section for properties. You might think that “Show All Properties” at the bottom would do it, but no. You need to hover your mouse over the “Properties” title, and select the dropdown arrow. You will be rewarded with two options, and we want the first one, “Show Document Panel.

The good part is, you only need to set it once, and it sticks. If you’re setting it for a template, it’ll stick there too. Once selected, you will be returned to the document and the document information panel will be displayed.

You should see all of the metadata fields that you created for the list, in their proper column order, using the appropriate controls for their data type. Any metadata changes made in SharePoint will be reflected here, and conversely, SharePoint will be updated with any of the changes entered here. This is helpful, but it’s really powerful when you use the metadata to help form the document.

5. Quick Parts – Put the Metadata to work

To use a metadata field in the document, position your cursor where you would like the field to be displayed (or edited), click the “Insert” ribbon tab, select the “Quick Parts” button, select “Document Property” from the dropdown, and finally select the field that you want to use.

Repeat the procedure for each field that you want to use. When finished, your document will look something like the following:

Finally, Save your template, and exit Word. You’re pretty much done.

6. Test the Template

After you close Word, you should be returned to your library. To test your template, you’ll want to try creating a new document. Go ahead and do so – click on the Documents tab in the toolbar, and the click on the new document button.

Go ahead and enter in the metadata values. Notice how the document updates as you do so. When complete, your document should look something like the image below:

Finally, save the document, and exit Word (or just exit). You’ll likely be prompted for a name – give it one. After Word closes refresh the library view, and you should see your document, with all of the relevant metadata in the library view.

B – Using A Content Type Template

Modifying a library template is relatively straightforward, but it does entail several limitations. Firstly, by using library defined metadata (and template) you are limiting yourself to only that library. Neither these fields nor this template can be used elsewhere in the site or site collection. In addition, all of the documents in the library must use this metadata definition.

In order to move beyond this limitation, SharePoint 2007 introduced the concept of Content Types. A detailed discussion of content types is beyond the scope of this article, but simply put, a content type is a collection of metadata fields that can be applied to a document. A content type is loosely analogous to a class in object oriented programming.

Luckily, content types contain not only metadata, but also documents. That means that we can define a content type in a similar fashion to the way we modified a list in the example above, but we can then take that content type and apply it to any library in the site collection. With the content type syndication features available in SharePoint 2010, we can apply it to any library in our organization (it’s no longer limited to even the farm). In addition, by using content types, any given library is no longer limited to a single set of metadata fields.

The process for creating a content type template is similar to creating a library template, but there are a few important differences. Where identical, I will reference the library template procedure.

1. Create The Content Type

Content types can be created at the site level or the site collection level. They will be available to their containing site and all sites below. If the content type is created at the root of the site collection, it will be available to the entire site collection.

To do this, navigate to the root site and select “Site Actions” and then Site Settings

You will then be presented with the Site Settings page. The Content types are stored in the Content Type Gallery, so next we will select “Site Content Types”.

We are going to create the “Letter” Content Type, so go ahead and click the “Create” button. You will then be taken to the Content type creation screen. This is similar to creating the new list as we did in the example above, but this time, there are additional options that control how the content type works.

We’ll be calling this content Type Letter, and it will inherit all of the properties (things like Name, and title) from the “Document” content type, which is in the “Document Content Types” category. Finally, we’ll want to group all of our content types in the same group, and since we don’t already have one, we’ll create the “My Custom Types” group.

Once created, we can add all of our custom fields to the content type. We’ll use the same fields that we did in the example above.

2. Add Metadata to the Content Type

Upon creation of the content type, you should be taken to the Content Type Information page for it. From here, go ahead and add the same columns that added to the list above.If you bump into a reserved or in use column name (i.e. First Name) either use a different name (ie Recipient First) or use the existing site column. Also, don’t forget to put all of the new columns into a group for later maintenance). When complete, the information page should look similar to the screen shown below.

Content types have some additional controls that allow you to control how the Document Information Panel appears within Word. In the settings section, Click on the “Document information Panel settings” link. On the next screen, ensure that the “Show Always” option is selected.

You should also note that this is where you can control precisely what appears in the Document Information Panel. Should you choose to do so, you can replace the default panel with an InfoPath form, but I won’t be covering that in this post.

Once you are ready, click OK.

3. Create an Word File and Upload it

When a document library is created, a document template is normally created along with it, unless specified otherwise. This is not true for content types. Therefore, We need to create a document to use as the template for this content type. Initially the process is very straightforward. Start Word, create a new document. If you want to add content to the document at this point, that will work, but it’s not necessary. When ready, save the document to your file system and remember its name/location.

Once done, go back to the content type definition window, and click the “Advanced Settings” link. in the resulting window, click the browse button, and navigate to the file that you just created.

Click OK, and then navigate back to the site. The content type is complete – for the moment.

4. Add a Library for Template Customization

Although we can edit the template once it’s been added to the content type, we can’t do anything with the metadata fields. That’s because Word can only reach back into the library that contains a document to see the metadata fields (the columns), and the content type gallery does not contain the columns that the content type itself does. We therefore need to create a document library that will use our content type. We will then create a new document that uses this content type, configure it the way we wish, and then replace the content type template with this document.

Firstly, add a new document library to a site (ideally the root site). We will be using it again below, and ultimately to house other document templates, so give it a logical name, something like “Document Templates”. Once created, we need to enable content types, and choose the our content type.

To enable content types, first navigate to the new library, and from the Ribbon, click the Library Tab, and then click the Library Settings button. From the Library Settings page, click the “Advanced Options” link. Once on the Advanced settings page, set “Allow management of content types?” to “Yes”.

Notice that the document template setting is greyed out. That’s because the content type will control the template. Click OK to close the advanced options screen.

You will now notice that we have a content types section, and the Document content type is being used. We want to add our content type, and then remove the generic Document content type. Since a library must have at least one content type, we must first add ours, and then remove the Document type.

First, click the “Add from existing site content types” link.

The “Add Content Types” dialog is loaded. Select your group from the dropdown, and add your content type to the Add list.

Click OK when ready. You will be returned to Library Settings, and you should now see your content type as number 2 in the list. We now want to remove the Document type, but there’s a slight catch. It is the first item in the content type list. The first item is the default content type, and the default content type cannot be deleted. We must first therefore make our content type the default, and then we can delete the Document content type. To do this, we click the “Change new button order and default content type” link.

From the next page, set the order of the Document content type to anything other than 1.

Click OK, and then click on the “Document” link in the Content Types list. You are then taken to the List Content Type settings screen. From here, click the “Delete this content type” link, and confirm. Note that you are NOT deleting the Document content type itself, but only its association with this document library.

You should be returned to the Library Settings page, and see only one content type. Return to the library to perform the next step.

5. Create a New Document in the Library

From the library, click the Documents tab on the ribbon, and the the New Document button.

Accept the confirmation, and Word will open. You will not need to turn on the Information Panel, as that is controlled by the content type itself. Recreate the letter following the procedure laid out in step 5 above.

Once you finish using Quick Parts, save the letter back into the library (this isn’t absolutely necessary for what we’re doing right now, but will help us in the last example). Once saved to the library, save it once again, but this time to your file system, and take note of the location/name.

6. Replace the Existing Content Type Template

The content type template that you had originally created was blank, but was necessary for the content type to work at all. We now need to replace it with our formatted letter template. To do so, we need to navigate back to our site content gallery (Site Actions – Site Settings – Site Content Types). Locate and click on the site content type created above (Letter in this case), and the content type information screen appears. Click on advanced settings, and replace the existing template with the new one by uploading the new one.

Close this window and return to your site. We’re ready to test this out.

7. Consume the New Content Type

Create a new library to test this. Configure it to use content types, add the new content type and remove the default Document content type. I’ve already outlined the procedure for doing this above with the template library, so I won’t repeat it here. Create a new document, change some of the metadata values and save it.

If you will not be using the procedure outlined below for template maintenance, you can delete the template library at this point.

In order to make changes to the template at this point, you will need to repeat the procedures in steps 5 and 6, immediately above, but you will be able to do this from any library configured to use this content type. There are a few down sides to maintaining the template in this way. For one, it is cumbersome, and for another, the ability to modify site content types, particularly at the root level is very high (or at least it should be….). This is a problem because you don’t necessarily want to charge farm administrators with the task of keeping document templates current.

Below, I will outline the last example which allows you to edit the template simply by editing a document in a library.

C – Using A Library to Manage Your Document Templates

So far, we have set up our template using our library metadata and stored it within our content type definition. We can use that content type throughout our site collection, but what happens when the requirements change for the site collection? In that case, someone with authority to do so must locate the content type definition, and repeat some of the steps above to update it.

If we centralize our document templates into a single, or even multiple document libraries, it makes for easier maintenance. It will be necessary for the template library to use all of the content types that it also contains, in order to do metadata maintenance.

The good news it that if you have been following along, you have already completed steps 1 and 2 below when you created the template library. Given that we’ve already been through many of the key concepts, I’ll keep the below examples brief.

1. Create a Template Library

If you have not already done so, create a new library for containing document templates. Go into advanced settings and enable content type. Add the content type of the template that you wish to manage. If necessary, delete the default “Document” content type.

The detailed procedure for doing this can be found above.

2. Add the Template to the Library

Either upload or create the document to be used as a template. Edit the document to suit your purposes.

3. Use the Document Directly as the Content Type Template

Here is where we deviate from where we have been before. First, you’ll want to take note of the URL of the file that you used in step 2. I make it a practice to always use relative URLS, which is everything to the right of the web application in the URL of the document. If your site collection is not at the root of the application, you will need to include the site collection path (i.e. /sites/mysitecoll).

The easiest way to get the document URL is by opening it in Word and getting it from the document information panel (File-Info).

Navigate to the site content type gallery (Site Actions, Site Settings, Site Content Types), and open your custom content type. When the information screen opens, click the Advanced Options link. The document Template URL will be set to the file name of the current template (if one has been created). Replace that with the URL of your document in the library.

Click OK, and return to your site.

4. Test it Out

If you don’t already have one, go ahead and create a new document library and have it use this content type. Create a few documents. As an added bonus, go back to the content type and add a mew metadata field. Edit the template in the template library to use this new field somewhere in the body of the document. Finally, edit one of the documents that use this template, and you should see the new metadata field appear in the Document Information Panel. If you create a new document, you should see the changes that were made to the template itself.

If you’ve made it this far, congratulations! Hopefully this demonstrates the power of content types combined with document templates, and helps provide some guidance on their use.

22 Comments

SharePoint Loses Access to Central Admin Content Database

Published February 1, 2011

I had a nasty problem with a client today that was running SharePoint 2007. They were doing some SQL database maintenance and inadvertently wound up with some problems with their msdb system database. They were able to get these rebuilt, and SharePoint appeared to work just fine. However, when I attempted to access the Central Administration application, I received the highly instructive “Unknown Error”.

The event log of course had a string of errors in it, most of which were Event 3760, with details below:

Cannot open database “SharePoint_AdminContent_ae0bba59-2a40-4110-8e9b-de1dcbbefc1f” requested by the login. The login failed. Login failed for user ‘xxxxxxxxx’.

SQL Server logs were also showing that access was denied, but the service account in question not only had all of the correct SQL roles, it was also the DB owner. This was obviously not actually a permissioning problem. The user could connect through SQL Management Studio, etc.

My next attempt at a solution was to remove, and re-add the Central administration application from the server using the Products and Technologies configuration wizard. That didn’t help at all, as it was simply referring to the same database, The problem obviously existed within SQL Server itself.

I could have removed the server from the farm,but that wasn’t something that I wanted to deal with,and the client wanted to prevent any more down time than was absolutely necessary. What finally worked was to create a new SQL database from a backup of the old one, and then configure Central Administration to use it. This also had the side benefit of removing the only remaining database in the farm with a GUID in its name.

The exact steps required to do this were:

Take a full SQL backup of the Administration Application content database.
Run stsadm –o deletecontentdatabase –url http://myurl:myport –databasename olddatabasename
Run SQL Management Studio and Detach the old content database. Either delete it, or move it to a new location. Don’t forget to do the same with the transaction logs
Restore the content database backed up in 1 to a new name (preferably without GUIDS). Watch the filenames (under the options tab) and use the overwrite option
Run stsadm –o addcontentdatabase –url http://myurl:myport –databasename newdatabasename

You should be good to go after this. This procedure also works if you just want to rename your Central Admin content database.

Setting up WordPress on Windows and SQL Azure: A Walkthrough

Published January 28, 2011

NOTE – July 17 2012 – The post below was originally written in early 2011, and represents the effort required to get WordPress working in an Azure Web Role. With the release of the new Azure IAAS features in June 2012, I wanted to note that I do not recommend this approach. I am leaving the post here as it may have historical value, or value for those using the tools described. WordPress can now be run as an Azure Web Site, or, as this blog is using, within an Azure Virtual Machine

As I mentioned in a post last week, the blog that you are currently reading is now hosted on Windows Azure. Nothing about the blog platform has changed, it’s still running on WordPress, but along the way I did switch the database from MySQL to SQL Azure. The process of getting this up and running was not exactly straightforward, so I thought that I would share my experience here.

To be clear, I am new to Azure. Brand new. What I’m writing below is simply my experience in getting this up and running, which happily I was able to do. This should not be taken as prescriptive guidance – that MVP badge at the top of this blog is for SharePoint – not Azure. If this helps you, then great. However, I would be happy to receive comments about mistakes, better approaches, or just other approaches.

Your mileage may vary – you’ve been warned…..

Since the Windows Azure operating environment is actually a Virtual Machine running Windows Server 2008 or 2008 R2, you can technically run anything on it that you can with either of those environments. Getting an ASP.NET service up into the cloud is a snap with Visual Studio, but getting other platforms up there, Like PHP requires a bit more effort. Luckily, Microsoft recently published the Windows Azure Companion, which makes it significantly easier to install PHP and PHP based applications like WordPress and Drupal on Azure. We’ll be working with this tool extensively.

1. Create the Storage Account

The Azure Companion installs a series of files into blob storage, so it is necessary to have a storage account available. Log in to the Azure Dashboard, click on “Hosted Services, Storage Accounts, and CDN”, and select “Storage Accounts”. Once this has loaded, click on “New Storage Account”.

From the following dialog box, choose your subscription, enter a name (URL) for your account, and choose a region.

The URL that you enter can be whatever you like, but it MUST be unique across all Azure storage accounts. I also always choose a specific data center. Given that you are charged for bandwidth in and out of the data center, and my WordPress install will be using SQL Azure, I want to make sure that all data moving between my front end server and my SQL Azure server is within the same data center, and this is the only way that I know to do this. The Storage Account should be created fairly quickly.

2. Create the SQL Azure WordPress database

Since we will be using SQL Azure for data storage, its necessary to create the database ahead of time. To do so, log into the Azure Portal select Database, drill into your subscription and select your server, and click create.

Depending on your subscription, you may get different options, but you need to select a database name, edition, and maximum size.

You can select whatever you want for edition and size, but 1 GB should be more than enough for WordPress. Make sure that you remember the name of the database.

Finally, you’ll need to make sure that the Firewall rules are configured to allow access for Azure services. From the Server information screen, click on Firewall Rules.

Unless already selected, clicking on “Allow other Windows Azure services…..” will add a rule permitting your Azure services to access the database.

In addition, make note of the following information. You will be needing it when it comes time to setting up WordPress, below:

3. Install the Windows Azure Companion

You can download the Windows Azure Companion from here. You have three choices – the companion without SSL, with SSL, and the source code. The big difference between the first two is what endpoints are configured, and the source code obviously lets you change the entire solution. Unfortunately, since the solution package has not been configured for remote desktop access, working with the source code is necessary.

Why is remote desktop access necessary? Well, if you are absolutely satisfied that you can get everything configured perfectly in the solution package, then it isn’t but at this stage in the game, I just don’t have that much confidence. RD access lets me tweak things after deployment. The biggest reason for me however was that if you use the application installer in Azure Companion, it will want to install your WordPress Instance in a subdirectory off the root (ie http://blogs.cloudapp.net/MyBlogName). I didn’t want that, I wanted to use http://myblogname.mydomainname.com, and to get that going requires a few modifications to IIS afterwards – hence the need tor RDP access. However, if the default behaviour is OK for you, download the precompiled solution package, follow the instructions here and skip to the next section.

To Edit the Solution you will need Visual Studio 2010 along with the Windows Azure Tools 1.3 SDK installed. You will also need to download the Azure Companion source files. Once done, open the solution file. There are actually 2 to choose from, one using SSL and one not. We will be working with the non-SSL Solution.

The “AdminWebSite” role is what we’ll be working with. This is the central application for Azure Companion, and from there we’ll install PHP and WordPress. For now, we are primarily concerned with configuring the role, and setting up Remote desktop. In addition, we’ll create a certificate to be used both for the application and for management (Remote Desktop).

First we need to configure the role, and we do that by double clicking on the role name in the roles folder. his brings up the Configuration tab.

The defaults on this page are fine, but the Instance Count is worth noting. According to my testing, Azure Companion can only be used with one instance. This is because multiple instances need to share a common file in the Blob storage, and this file is locked by the first process that accesses it. This will generate an availability warning on deployment.

The settings tab is where most of the configuration is performed.

There are 5 values here that MUST be configured:

WindowsAzureStorageAccountName	The name of the storage account created in step 1
WindowsAzureStorageAccountKey	The storage account primary key that can be obtained from the portal after the account has been created
AdminUserName	A new user name that will be used to administer Azure Companion
AdminPassword	Administrator’s password
ProductListXmlFeed	A list of available products to install. Azure Companion is extensible, and you can maintain your own list*.

* There is a publicly available feed at : http://wazstorage.blob.core.windows.net/azurecompanion/default/WindowsAzureCompanionFeed.xml

Once these settings are made, we need to modify the endpoints. Azure allows for 5 endpoints, and if Remote Desktop occupies one of them. On the surface, the 4 endpoints specified should be fine, but my testing showed that either there is a hidden endpoint somewhere, or the limit is actually 4. Either way, we need to remove one of the endpoints. We have no need for MySQL, so that’s the one that loses.

The rest of the settings are fine, so we don’t need to explore them. At this point it’s a good idea to save the project. If you get a write protected error, you’ll need to go to the folder where the project files are stored and remove the read only attribute from the project files. Don’t forget to come back and save the project.

While Visual Studio can deploy directly to Azure, for the first deployment, we have a bit of a chicken and egg problem. In order to deploy a solution that has Remote Desktop enabled, you need to have a service certificate and management certificate already available. The service certificates are installed as a node under the hosted service, but the hosted service hasn’t yet been created. Further, to create a new hosted service from the portal , you need to have the two package files available. Therefore, for our first deployment, we will create the service files and deploy manually.

Right click on your cloud project, and click “Publish”.

In this case, the default value of “Create Service Package Only” is what we want, so click on “OK”. Visual Studio will then create the files that we need to deploy, and open up a Windows Explorer window to the path in which they’re contained. Copy this path to the clipboard, and we are now ready to create our first Service Application.

Open the Windows Azure Portal, click on Hosted Services, and then click “New Hosted Service”. The new Hosted Service dialog appears.

The Service name only matters for management purposes, but the URL Prefix is the way that your application will be addressed from outside, so choose the name wisely. It must be unique among all Azure applications. For the region, make sure that you choose the same region specified for the SQL Azure database above. Since you likely won’t need deployment/production environments, just deploy to production. We’ll be changing this right after we create it, so we don’t want to start it, that just takes extra time. Finally, select the package and configuration generated by Visual Studio.

Once this is done, Azure will create the virtual machine to host the instance, and install the instance itself. The process will take a few minutes, but when you’re ready to proceed, The portal window should appear something like the window below.

The next thing that we need to do is to create our service and management certificates. The two certificates can be based on the same root certificate but must be in two different formats. The management certificate will be a .cer file (which is what is created when a self signed certificate is created) and the service certificate must be in X509 format. This can be done by exporting a .cer file.

If you already have a certificate, you can skip this creation step, but to create one, the easiest way is to use the Visual Studio tools. Once again, Right click on your cloud project, and click “Publish”. This gets a little tricky.

Click on the credentials drop down and select <Add>. Then, the Project Management Authentication dialog appears. Again, select the drop down, and if there are no credentials already stored, choose <create>. Then enter a friendly name for the certificate (in this case sfiWordPress). Follow the instructions in step 2 – but note that there is no “Subscription Page”, but that you’ll be uploading a Management certificate into the Management certificate section. The subscription ID is obtained in the portal and the purpose of naming the credentials is so that Visual Studio can refer to them at a later date.

When ready, click OK. VS will connect to Azure to make sure that everything OK, and load in all of your hosted services. However, we’re still not quite ready to redeploy. First we need to upload a service certificate to the service (we did the management certificate above). This is because we need such a certificate in order to use Remote Desktop.

First, we need to create our certificate, To do so, click the “Configure Remote Desktop connections link”.

Create a new certificate if necessary, and enter in a local machine (for the service) user name. When ready click OK. We’re almost ready to deploy, but first we must upload this new certificate to the service. However, it’s not yet in an importable format, so we need to export our certificate to a .pfx file. To do so, without closing our deployment dialog, run the certificate manager add in by clicking on the Start Pearl, and entering certmgr.msc into the search box:

When the certificate manager window opens, open the Personal branch, and click on Certificates. Then, right click on your new certificate, hover over all tasks, and click on Export.

The certificate export wizard will then start. Walk through the wizard, make sure that you select the option to export the private key, enter (and Remember!!!) a password, enter a file name and save it. When this is done, we’re ready to add it to our service application.

Go back to the Azure Portal, and navigate to your hosted service. Then click on the certificates node, and press the “Add Certificate” button in the ribbon. Browse to the certificate, and enter its password. When ready, click the create button.

Now we’re ready to deploy our Remote Desktop enabled service. Go back to the Visual Studio Publish Dialog, make sure that you have the deploy to Azure option selected, and click the OK button. If all is well you will receive the following prompt:

This is simply warning you that you have another service deployed into the production slot, and that you will be overwriting it with this deployment. Since this is precisely what we want, go ahead and click the “Delete and Continue” button. The deployment process will take several minutes. I suggest going for coffee, or pursuing another vice that requires 5-10 minutes.

4. Use Azure Companion to Set Up PHP and WordPress

Once started, the Azure Companion management service is running on port 8080. You can access it by navigating to your service URL at that port. In this case, it’s http://sfiwhitepages.cloudapp.net:8080. You should see a screen similar to the following:

You log in with the ID created in the service definition in Section 3. If you receive errors, chances are that all the services haven’t spun up yet. You will also receive errors here if you configures multiple instances of the service, because both instances are trying to access the same file.

Click on the Applications tab. You will find a number of applications listed, and the one we’re interested in is WordPress. Selecting it and click next. The next page will show it selected, along with all of its dependencies, including the PHP runtime, and the PHP SQL drivers.

One parameter above is quire important, the installation path. This path will be used to form the URL to your blog, in the form http://serveraddress/InstallationPath. Unless you’ll be taking the additional steps to install the blog into the root that I describe below, you’ll want to choose this name wisely, as you’ll be handing it out.

After you have carefully read all of the licence terms (tee hee), click the “Accept” button. All of the requisite files will be installed for you. This process should take something less than a minute. When done, you will be returned to the application screen. You are now ready to set up WordPress. To begin the process, click on the launch button in the application window:

Alternatively, you can enter the URL for WordPress on your service by adding the installation path to the end of your URL, i.e. http://sfiwordpress.clousapp.net/wordpress. Doing so will begin the WordPress configuration procedure. You should be presented with a page that indicates that the WordPress configuration file needs to be created. Go ahead and do so. After a confirmation page (click “Let’s go!”), you’ll be prompted for the database connection information. Here you’ll enter the information that you recorded at the end of the SQL Azure setup step above (step 2). The format of the user name is a little non standard (username@machinename), but the diagram below shows how the information from step 2 maps to the WordPress setup form.

Clicking Submit causes WordPress to check the connections, and if all is well, you are prompted to Run the install. Clicking the install button brings up the standard WordPress configuration screen, looking for the Site Title (for use on pages), the administrator user name, the administrator password, and your email. WordPress will use your email for things like administrator password resets, but the sendmail function will not work, at least without further setup (which I haven’t done). In other words, don’t forget the password.

Once complete, go ahead and click the “Install WordPress” button. You’ll receive a confirmation message, and clicking on Log In will take you to the login screen. Once logged in (as the administrator), you’ll be taken to the standard WordPress admin screen.

Of course navigating to the blog’s address will take you to the blog itself.

If you’re happy with the URL as is, you’re done. However, if you’re like me, and you want to have the blog at the root, and/or you want to use your own domain to host the blog, then read on…..

5. Move the Blog to its own Application

Once installation is complete, WordPress is stored in a subdirectory of the main PHP host site. If we don’t need the site for anything else, then we can change its port bindings, create a new web application on port 80, and move the WordPress files to it.

The first step is to connect to your Azure instance with Remote Desktop. To do this, open up the Windows Azure portal, navigate to the service instance, and click the connect button in the ribbon.

This will open up the Remote Desktop window. You will log in with the credentials that you created in the Remote Desktop configuration settings in Visual Studio. When entering the User Name, make sure to preface it with a backslash (ie jwhite) to indicate a local user. If you used a self signed certificate, you will receive certificate warnings, but these can safely be ignored.

Once logged in, start the IIS Manager, then open up your virtual server, and open the sites tab. You should see two sites, one is the admin site for Windows Azure Companion, and the other is the PHP Host site. Our first step will be to change the port binding to something other than 80 for the PHP host site, so select it, and click on Bindings.

Select the current binding click edit, and change the port to something other than 80 (I used 81). Keep in mind that because this endpoint is not defined in the service, it will be unavailable outside of the host instance.

Next, open Windows Explorer and open up the F: folder. Create a new folder to house the WordPress files (in my case F:WordPress). This will be our new blog folder. The name will only matter to the server. Next, open up the F:Applications folder. This is the root of the current WordPress site. Copy the two files stored there (phpinfo.php and web.cfg) to the folder that you just created. Next, navigate to the folder in the F:applications folder (in my case, F:applicationswordpress) and copy everything there into the same new folder.

Once this is done, go back into IIS Manager, right click on the Sites folder, and select Add New Site.

Give the site a unique name, and for the Physical Path, use the new blog folder created above. Ensure that the app is explicitly bound to the server’s IP address, and in addition, ensure that the site is bound to port 80. When finished, the web site should start, but if there is an error, simply restart it.

You should now be able to navigate to the root of your site, but you will likely notice that all of your styles have gone. This is because WordPress still thinks it’s installed in the old folder. To fix this, you have two options. You could connect to your SQL Azure Instance with SQL Enterprise Manager, and edit the siteurl record in the wp_options table. Alternatively, you can navigate to the new blog folder, delete the wp-config.php file, navigate to the blog root, and re-set it up as above. This is likelier the easiest option, but be aware that before you do this, you will need to drop and recreate your SQL database.

We’re almost there…

6. Implement a custom Domain Name

OK. Now we have a WordPress blog running at the root of our application. However, if you’re like me, you likely want to use your own domain, and not cloudapp.net. Unfortunately, Azure uses variable external IP addresses, so there’s no way to use host headers and DNS A records. However, we can create a CName (alias) record that converts xxx.cloudapp.net to servername.mydomain.root.

The first step is to log in to your Domain Services provider. I use DynDNS so the example will be from there. Simply add a CNAME record that converts the Azure service name to your desired address. The DynDNS example is below.

You should now be able to navigate to your blog at the new address. It may take a few minutes for changes to propagate.

We have one step to go. WordPress is answering on this new address, but it will still form all of its URLs using the old one. We need to tell it to use the new address, and we do that by navigating to the admin app. Until we make this change, we need to use the old address, which in my case is http://sfiwhitepages.cloudapp.net/wp-admin.

Once logged in, click on settings along the left menu, and then select General.

Once those changes are made, you can use the new domain exclusively.

That’s it…we’re done! Easy right? It’s worth it. No longer is my blog at the mercy of my local power provider, or any IT maintenance schedules. As I mentioned at the beginning, please feel free to comment with any better approaches, or any egregious errors that I may have made.

13 Comments

The White Pages Posts