I’m running the site using a least priviledged model which requires me to add the contacts manually to AD.  Everything seems to work properly as long as I include some text.

I’m not sure if this is a SharePoint deficiency or an Outlook issue.  I will post a followup if I figure this out.

ShareThis

1. Do not install ESX 3.5 U2 if it has been downloaded from VMware’s website or elsewhere prior to August 12, 2008.

Hmm.. already installed the patch, guess that won’t work.

2. Set the host time to a date prior to August 12, 2008. This workaround has a number of very serious side affects that could impact product environments.

You better believe there are side effects. If you are synchronizing time with the ESX server Kerberos will complain bitterly if you set the clock back. Oh, and another thing, Exchange 2003 won’t even start as it appears to get its initial time from the host hardware clock at boot.

ShareThis

This is a huge foul-up on the part of VMware and will probably damage their credibility for some time to come.  The ability of one update to take down entire server farms will surely hamper adoption of virtualization for production servers across the board.  This is very unfortunate for VMware.

Dear VMware Customers,

Please find the latest update about the product expiration issue. From this point on, we’ll provide an update every two hours. Thanks.

Problem:

An issue has been discovered by many VMware customers and partners with ESX/ESXi 3.5 Update 2 where Virtual Machines fail to power on or VMotion successfully. This problem began to occur on August 12, 2008 for customers that had upgraded to ESX 3.5 Update 2. The problem is caused by a build timeout that was mistakenly left enabled for the release build.

Affected Products:

• VMware ESX 3.5 Update 2 & ESXi 3.5 Update 2
• Reports of problems with ESX 3.5 U1 with the following 3.5 Update 2 patch applied.
1. ESX350-200806201-UG
• No other VMware products are affected.

What has been done?

• Product and Web teams pulled the ESX 3.5 Update 2 bits from the download pages last night so no more customers will be able to download the broken build.
• VMware Engineering teams have isolated the cause of the problem and are working around the clock to deliver updated builds and patches for impacted customers.
• A Knowledgebase article has been published (http://kb.vmware.com/kb/1006716), but traffic to the knowledgebase is causing time outs. A new static page has been published at http://www.vmware.com/support/esx35u2_supportalert.html that customers and partners will be able to view.
• The phone system has been updated to advise customers of the problem
• Vmware partners have been notified of the issue.

Workarounds:

1. Do not install ESX 3.5 U2 if it has been downloaded from VMware’s website or elsewhere prior to August 12, 2008.

2. Set the host time to a date prior to August 12, 2008. This workaround has a number of very serious side affects that could impact product environments. Any Virtual Machines that sync time with the ESX host and serve time sensitive applications would be broken. These include, but are not limited to database servers, mail servers, & domain administration systems.

Next Steps:

VMware to notify customers who have downloaded this version and provide an update every two hours.

Resolution:

VMware Engineering has isolated the root cause and is working to produce an express patch for impacted customers today. The target timeframe is 6pm, August 12, 2008 PST.

FAQ:

1. What would this express patch do?

More information will be provided in subsequent communication updates.

2. Will VMware still reissue the upgrade media and patch bundles in the timeframe that has been communicated?

Yes. We still plan to reissue upgrade media by 6pm, August 13 PST (instead of noon, August 13 PST) and all update patch bundles later in the week. We will provide an ETA for the update patch bundles subsequently. NOTE: the “patch bundles” referred to here are for the patches listed above under “Affected Products” and the other bundles released at GA. They are not the same as the express patch which is targeted for 6pm, August 12, 2008 PST as stated above.

3. Why does VMware plan to reissue the upgrade media before the patch bundles? That is a wrong priority call!

This is not a matter of priority. Since we can get done building and testing the upgrade media before the patch bundles, we want to make that available to customers first instead of reissuing all the binaries later in the week.

4. Can VMware issue a patch that opens the licensing backdoor in the next hour as a critical measure?

There is no licensing backdoor in our code.

5. Does this issue affect VC 2.5 Update 2?

No.

6. What is VMware doing to make sure that the problem won’t happen again?

We are making improvements on all fronts. The product team had endeavored to deliver a release with support customers deem important. But we fell short and we are deeply sorry about all the disruption and inconveniences we have caused. We have identified where the holes are and they will be addressed to restore customers’ confidence.

ShareThis

Event Type: Error
Event Source: Kerberos
Event Category: None
Event ID: 4
Date: 01/01/2008
Time: 12:59:00 PM
User: N/A
Computer: XXX
Description:
The kerberos client received a KRB_AP_ERR_MODIFIED error from the server XXX$. The target name used was ldap/xxx.company.com. This indicates that the password used to encrypt the kerberos service ticket is different than that on the target server. Commonly, this is due to identically named machine accounts in the target realm (COMPANY.COM), and the client realm. Please contact your system administrator.

Using Kerbtray, I determined the user was receiving a valid Kerberos ticket from the front-end server and that ticket contained the proper service principal name (SPN). It appeared all DNS, forward and reverse, all delegations and all SPNs were correctly configured. The server was simply rejecting the user’s valid credentials. Following the clues from the event description, I began looking for duplicate or conflicting SPNs. I was unable to find any.

As other farms in our environment use the same basic configuration, I started to think this might be an issue with the secure channel, or domain account of the server. Since this was a new install, rebuilding the server wasn’t a big issue. Unfortunately the rebuild didn’t help. As soon as anyone tried to authenticate using Kerberos, they received the endless logon prompts. I was completely stumped until it occurred to me that what may be going on is exactly what the event indicated, but with a bit of a twist.

The theory I came up with was that the issue was not duplicate machine accounts, but duplicate keys. As the web application is an IIS virtual server and has a DNS name that is different from the server’s NETBIOS name, it was possible the server was sending the client the public key for the web application as configured in the SPN, but attempting to decrypt the packet using the private key associated with the server’s NETBIOS name.

To test the “multiple key” theory, I assigned two additional IP addresses to the server through the TCP/IP network settings. I then used the IIS manager to change the IP address for the SharePoint web application from “All Unassigned” to one of the newly added IPs. I repeated the process with the other new IP for the Central Administration site. All other web applications were left at the default “All Unassigned.”

After making the server changes and updating the DNS to reflect the directly assigned IP address, I rebooted the server. Once the server was back up, Kerberos authentication worked perfectly.

I’m not sure why it was necessary to statically assign an IP address to the web application as we have other farms that use the shared IP without issue. Perhaps it’s a hotfix, a .NET issue, or some obscure DNS anomaly. Whatever the case may be, we have reassigned all front-end servers with static IPs as a best practice and haven’t had a Kerberos issue since. If I ever find out the exact cause of this, I’ll post an update.

ShareThis

SharePoint relies heavily on DCOM and as such, requires additional access rights to several DCOM objects. Microsoft makes no assumptions about your SharePoint security model and only provides default access to DCOM objects for administrators, system, and a few select user and group accounts. The SharePoint install will add the farm account to some of the DCOM objects, but unless you’ve used that account for all your SharePoint services and made that account a server administrator, SharePoint will not have the necessary permissions to operate properly.

If you didn’t follow best practice and used a single account for all SharePoint services, you could easily eliminate all these errors by making your SharePoint account a local administrator. That, however, would be considered a most privileged model installation which is not advisable for several reasons, the primary being security. If you run your web server under an account with administrator privileges and your IIS server is compromised, any malware that a hacker could get onto your machine would run under the security context of the account running the web application pool. This is especially bad if the account running IIS is also the farm account. The hacker could now potentially gain access not only to your server, but to your SQL databases as well. It’s easy to see why running your MOSS install under non-privileged accounts is a good idea.

To complete your install and eliminate DCOM errors, you will need to make several security changes to two DCOM objects and two permission changes in your shared service provider. As I stated before, simply making the accounts in question local administrators will solve the issue, but as you now know, that’s not a good idea. We want to grant the minimum object permissions possible and still have a functioning system.

If you are experiencing Event ID: 10016 and Event ID: 7888 DCOM errors you will see these entries in your event logs:

Event Type:      Error
Event Source:     DCOM
Event Category: None
Event ID:     10016
User:          NT AUTHORITY\NETWORK SERVICE
Description:
The application-specific permission settings do not grant Local Activation permission for the COM Server application with CLSID{61738644-F196-11D0-9953-00C04FD919C1} to the user NT AUTHORITY\NETWORK SERVICE SID (S-1-5-20).  This security permission can be modified using the Component Services administrative tool.

Event Type:     Error
Event Source:     Office SharePoint Server
Event Category: Office Server General
Event ID:     7888
User:          N/A
Description:
A runtime exception was detected. Details follow.
Message: Retrieving the COM class factory for component with CLSID {61738644-F196-11D0-9953-00C04FD919C1} failed due to the following error: 80070005.

These errors occur when the application pool accounts do not have sufficient privileges to the IIS WAMREG admin service. To correct the errors, add local launch and local activation permissions for all application pools to the IIS WAMREG object.

You may also receive this error for:
CSLID {3D42CCB1-4665-4620-92A3-478F47389230} which is the OSearch object that is discussed below.

To permission the IIS WAMREG object, open “Start/Settings/Control Panel/Admin Tools” and double-click on “Component Services.” Navigate to “DCOM Config” under “My Computer” and right-click on the “IIS WAMREG admin Service” object and select “Properties.”

Next, select the security tab and edit “Launch and Activation Permissions.” Make sure that your farm account (account that accesses your SQL database) and all your application pool accounts are granted both local launch and local activation rights. Select “OK” then “OK” again when finished.

If you are experiencing Event ID: 6398 and Event ID: 6482 errors you will see these entries in your event logs:

Event Type: Error
Event Source: Windows SharePoint Services 3
Event Category: Timer
Event ID: 6398
Date: 01/01/2008
Time: 00:00:00
User: N/A
Computer: XXX
Description:
The Execute method of job definition Microsoft.Office.Server.Search.Administration.IndexingScheduleJobDefinition (ID d2784cd2-20cf-466f-b5f0-365e65cdf542) threw an exception. More information is included below. Retrieving the COM class factory for component with CLSID {3D42CCB1-4665-4620-92A3-478F47389230} failed due to the following error: 8007000e.

Event Type: Error
Event Source: Office SharePoint Server
Event Category: Office Server Shared Services
Event ID: 6482
Date: 01/01/2008
Time: 00:00:00
User: N/A
Computer: XXX
Description:
Application Server Administration job failed for service instance Microsoft.Office.Server.Search.Administration.SearchServiceInstance (3ede7ca8-f6f6-432a-bd4b-cd8478ab6810).

These errors occur when your default content access account (account used for search and indexing) and your shared service provider service account do not have sufficient launch, activation and configuration permissions to the OSearch DCOM object. Referring back to the images above, locate the OSearch object and apply the following permissions:

1. Grant local launch and activation rights to your farm, default content access and shared service provider service accounts.
2. Grant full control to the configuration permissions to your farm and default content access accounts.

Finally, there is one other issue related to profile imports that some installations experience. This issue is solved through SharePoint permissioning in the SSP.

If you are experiencing Event ID: 7888 runtime exception errors you will see these entries in your event logs:

Event Type:    Error
Event Source:    Office SharePoint Server
Event Category: Office Server General
Event ID:    7888
Date:        01/01/2008
Time:        00:00:00 AM
User:        N/A
Computer:    XXX
Description:
A runtime exception was detected. Details follow.
Message: Access Denied! Only site admin can access Data Source object from user profile DB.
Techinal Details:
System.UnauthorizedAccessException: Access Denied! Only site admin can access Data Source object from user profile DB.

This error is caused by insufficient SharePoint permissions for your default content access account. This problem is corrected in Central Administration under your shared service providers “Personalization Service Permissions.” Open your Central Administration site and navigate to: “Shared Services Administration: Primary SSP > Manage Permissions.”  (Note: your SSP may be named differently)

Give your default content access account and your search service account “Manage User Profiles” rights. In my case, I use the same account for the search service as well as the default content access account. If you use different accounts, add permissions for both.

This concludes the basic permission granting tasks required for DCOM objects under a least privileged MOSS install. Depending on the particulars of your install, you may be required to troubleshoot additional DCOM issues. The basic troubleshooting methods include identifying the object in question and identifying the actual error. Keep in mind, the event ID is not the error; it’s the event the error triggered. For our IIS WAMREG and OSearch issues above, the actual error was “80070005.” This is an access denied error and one of the most common DCOM issues. If you are seeing 8007005 errors listed in your events, you can be sure it’s permissions related. Unfortunately, Microsoft doesn’t tell you right off what object is causing the trouble. Instead you are given a CSLID identifier and it’s up to you to figure out what it is.

Luckily, the human readable names of CSLIDs are easy to identify. Simply select the CSLID, including the {}’s, open the registry editor and search for it. If you carefully poke around, you will eventually be able to associate the CSLID with the name of the DCOM object.

If you have any additional questions about this article or about the least privileged model in general, please leave a comment or post to our forum. I will attempt to answer your questions as soon as possible.

ShareThis

Recently I received a burst of traffic from a reference citation on the popular tech site, Experts Exchange.  When I went to the source to check on what it was all about, the referenced link back to my site was not very pretty; in fact it was downright ugly!  The link supplied by the poster at Experts Exchange was in response to a previous question asked by a user.  It was simply -

also here:
http://www.os.com/?p=9

For a search engine result, this link isn’t an issue, as the results page will include the post title and a brief content snippet.  But for a manually entered link, the reader’s experience isn’t quite the same.  The default permalink doesn’t provide the potential reader with any incentive to click through to the article.  The URL is totally generic and non-descriptive and for all they know, it could be a spam link.  This was something I hadn’t considered.  In the past I was only looking at how search engines would view the URLs, not people.  Unless all one is interested in is ad clicks, a blog should be written for people, not computers.  This alone was enough to convince me to change the permalinks.

The other reason has more to do with overall design considerations than anything else.  I’ve been thinking of expanding the site with additional content and was contemplating moving the blog one level lower in the site hierarchy.  While I could easily re-install WordPress in a sub-directory, doing so would require an additional content management system for the non-blog portion of the site.  I like WordPress and it works fairly well as a CMS.  I have no desire to add yet another management layer to the site.  With WordPress, simply changing the permalink structure is an easy and effective way to push the blog content down a level without the need for a major re-design.  So now that I’ve decided the ugly permalinks needed to go, all that is left is to decide on the optimal permalink format.

There are literally hundreds of posts detailing the ongoing debate over the best permalink structure.  Most of these debates revolve around search engine optimization.  As I have stated before, I don’t believe SEO considerations are germane to a URL formatting decision. Your permalink structure decision should be based on how people interact with your site, not search engines.  Although there are several popular formats that are sound from a design standpoint, in practice they could be technically troublesome.

One popular format is the /%category%/%postname%/ structure.  While this method looks good at first, it suffers from two potential problems.  First, if you ever decide to change your category structure, or move your posts between categories, it will cause havoc with both links on search engines and referring sites.  Second, if your categories contain sub-categories, or your posts are listed in multiple categories, you may experience unpredictable URL paths.  The category WordPress will use is not necessarily the category you want.  WordPress will select the category with the lowest category ID.  Remember, pretty permalinks are the result of the rewrite engine.  WordPress still uses the ugly permalinks internally.

The other method, and I believe the most popular one, is simply using /%postname%/.  From a people standpoint this is the simplest and most descriptive URL.  It does, however, lock your blog at the root of the site.  In my previous post I stated this was good thing, but that was before I decided I wanted to add additional non-blog content to the site.  My preference now is for flexibility as well as readability.  So long as your posts aren’t buried in what looks like a long directory path, having your blog at the second level of your site shouldn’t be a problem for search engines or people.

There is also one other format that I have recently seen that is based on /%post_id%/%postname%/.  I’m not sure what to make of this design.  Creating a URL that contains a unique post ID as a path element doesn’t seem to serve any practical purpose.  It can also hinder user interaction with the site.  How often have you been on a site and manually edited the URL in the browser bar to navigate back to a previous directory?  Using /%post_id%/ in the path makes this type of navigation impossible.

After debating the pros and cons of the various link formats, it came down to either /articles/%postname%/ or /blog/%postname%/.  I decided on /blog/%postname%/ for a couple of reasons.  Having the word “articles” in the URL path is descriptive, but not necessarily accurate.  An article is really something different than a blog post.  Articles are generally longer and more formal.  I felt the posts here, although some are long, are not technically articles.  Blog is a much better description.

Readers identify blogs with dynamic Web 2.0 content.  Articles are static in nature, more like reference material.  Selecting /blog/%postname%/ seemed like it fits both my structure and design requirements.  Now the only thing left to do is to make sure I haven’t created lots of duplicate content.  One of the major advantages of the default structure is that it helps reduce duplicate content which will definitely affect SEO.  Now that I’ve changed link structure, I need to be more aware of the potential for duplicates.

As the content is now available through multiple URLs, I needed a way to control how search bots indexed the site.  I decided on using the Robots Meta plugin from Joost de Valk as it provides granular control over what and how the site is indexed.  This seems a little less ham-handed than messing with the traditional robots.txt.

So now, after eating crow, I’m ready to implement the new structure.  I hope I will not feel the need to switch it back because that will make a real mess with search engines, RSS feeds and manually entered links.  Changing your permalink structure from the default is something you only want to do once.

ShareThis

I needed a method that wouldn’t require additional hardware or third party tools so I decided to try a simple export / import with stsadm. The procedure was much easier than I expected and after several test runs, I was ready to clone the site. The entire process took less than an hour (1GB data) and except for a few minor issues, I was able to create an exact replica of the production environment with a new application name.

Although this is a good method for renaming or cloning applications, I want to stress this is not a good method for building a development environment. Since all the web parts, databases and hardware are still shared with the production system, any changes to the base SharePoint environment of the clone will affect the original. A development or test environment should always remain isolated in its own farm on different hardware.

Procedure to create a duplicate MOSS instance in the same farm

1. Verify you have a proper backup of your source application.
   
2. Create a new target web application using a different name. For example; if the source application is http://sourceapp/, then create an application named http://targetapp/.
3. Create a site collection at the root of your new target application using the same template that was used to create the source application.
   1. Note: If you are using custom templates, this template must be the same version as the source site’s template.
4. Export the source site content and structure.
   1. stsadm –o export –url http://sourceapp/ –includeusersecurity –haltonwarning –filename c:\filename.cab
   2. You must export each sub-site separately. I.e. http://sourceapp/, then http://sourceapp/site1, etc.
5. Deploy and activate all solutions and web parts on the newly created target web app.
6. Take target server’s database offline at “Central Administration > Application Management > Content Databases > Manage Content Database Settings.”
   
7. Import each exported cab file into the new web application.
   1. stsadm –o import –url http://targetapp/ -includeusersecurity –haltonwarning –filename c:\filename.cab
   2. Repeat for each sub-site.
8. Put database back online.
9. Pay particular attention to Issue #2 outlined below.

Issues you may encounter

1. Due to small template inconsistencies, some sites may display the following page:

   

   This problem can be fixed by copying the “Default.aspx” page from a working site (in the same web app) to the root of the non-working site. This is accomplished through the “Manage Content and Structure” page of the web app. You must first delete the corrupted “Default.aspx” page before copying in the “good” page.

2. Please be aware that any links in the source app that are entered with the FQDN, will retain that FQDN when the site is exported/imported. This could allow the accidental editing of the source application’s data from the target application. The user will click the link thinking they are accessing the page on the duplicate server when they are actually redirected to the source server.

   To correct this issue, the source server should be carefully edited to replace all FQDN links with relative URLs prior to export. Go to the navigation page of the effected site and remove the leading host header. For example: change “http://targetapp.mydomain.com/site1/Default.aspx” to “/site1/Default.aspx.” This ensures the link is directed to the local site and not the original site. This issue is primarily of concern to user created links. SharePoint created links are always relative URLs.

3. Custom header icons at the root of the sites may not be active even though they are imported into the web app. Correct this from the “Title Description and Icon” page of each effected site. Simply remove the reference to the default SharePoint icon and save.

ShareThis

Microsoft recommends applying these fixes as soon as possible.

You can find the patches at:

32 bit

Infrastructure Update for Microsoft Office Servers (KB951297)

Infrastructure Update for Windows SharePoint Services 3.0 (KB951695)

64 bit

Infrastructure Update for Microsoft Office Servers (KB951297)

Infrastructure Update for Windows SharePoint Services 3.0 (KB951695)

Join the forum discussion on this post - (1) Posts

ShareThis

Recently we experienced a rash of authentication issues when some users accessed a custom SharePoint web part that retrieves data from a MOSS farm hosted at a remote site. Although the target farm is in the same Active Directory (AD) domain as the source farm, this type of credential passing between IIS servers will introduce the “double-hop“ issue if the default Windows authentication method is set to NTLM. When a user accesses an IIS server in farm “A” and that server needs to pass the users credentials to an IIS server in farm “B,” authentication will fail unless the mechanism used is Kerberos. It doesn’t matter that both farms are in the same AD domain, only Kerberos will successfully avoid the “double-hop” issue.

In order for Kerberos to successfully pass credentials between IIS servers in different farms, both farms must be configured for negotiated authentication and have direct access to the same key distribution server (KDC). This means, both farms must either be in the same domain, or have a trust between domains. Kerberos doesn’t operate across un-trusted domains.

Knowing these requirements, we configured each MOSS farm for negotiated authentication and after solving several issues configuring Service Principal Names (SPNs) that I will discuss in a future post, we finally got our new custom web part working. After a couple of weeks, however, the help desk began to receive reports from several users that the web part was failing with authentication errors. Not finding anything wrong with the user’s profile or server permissions, the help desk issued its standard “reboot and try again” remedy when encountering unknown gremlins. This always seemed to fix the problem, at least temporarily. Unfortunately, after about a week, the support calls returned and it was usually the same users. That’s when I was put on the case.

Knowing this was an authentication issue and the authentication method was Kerberos, I grabbed my trusty kerbtray.exe and headed over to the user’s PC. It didn’t take long to figure out what was going on. Just looking at the Kerbtray icon in the system tray told me all I needed to know, “Kerberos – no credentials.”

“Do you logoff your PC when you leave the office?” I asked. “No” came the reply. “Do you ever logoff your PC?” I followed. “Well, only when it locks up or crashes” answered the now puzzled user. Finally, sounding somewhat like an irritated cop, I quipped “Well, there’s your problem, you’ve let all your Kerberos tickets expire.”

In some environments where applications are configured solely for Kerberos authentication, this may be a common problem. Contrary to what the Windows dialog box indicates when you issue the Ctl+Alt+Del, Windows doesn’t really have a log on / log off routine in the classic sense like say, a Unix shell. Instead you are granted access to resources until you either invalidate that access, or in the case of Kerberos, your tickets expire. This is what was happening to our users who were perpetually “logged in.”

With Kerberos authentication, when a user requests data from a remote server, that user’s PC will send a request for a session key to the local domain’s key distribution center (KDC). The KDC prepares two copies of the session key that both client and server will use for the authentication process. The client’s session key is encrypted with the client’s long-term key and the server’s session key is encrypted with the server’s long-term key. The long term key is derived from the user’s password.

The KDC then encrypts the client’s session key with the key it shares with the KDC. It also encrypts the server’s copy of the session key, along with the authentication data for the client with the key the KDC shares with the server. This packet then becomes the session ticket. Both the client’s session key and the server’s session ticket are then forwarded to the client PC.

When the client is ready to communicate with the server, the client decrypts its copy of the session key and uses it to encrypt an authenticator packet. The authenticator, along with the session ticket is forwarded to the target server. The authenticator and the session ticket now become the client’s credentials for access to the server. The server decrypts the session ticket, extracts its session key and decrypts the authenticator. If the authenticator decryption is successful, the server will allow access to the requested resource. If mutual authentication is required, the server will use the session key to encrypt a timestamp which it returns to the client. If the client is able to decrypt the timestamp and the time is within the configured limits, the client will know it is communicating with the proper server. For a more detailed explanation of the workings of Kerberos, see: http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/distrib/dscd_aun_yfet.mspx?mfr=true

Why did this problem only manifest itself with the custom SharePoint web part? Because all the other applications the user was using, such as Exchange, SharePoint, Windows file and print services, all fell back to the default NTLM authentication, which doesn’t expire until the user logs off the session. Only the application, which in this case was a web part, would fail when the Kerberos ticket expired. Interestingly, this NTLM fallback will occur even when the initial authentication was Kerberos.

In our environment, the tickets are valid for 10 hours and will automatically renew for 7 days. If the user doesn’t re-authenticate within the 7 day period, the tickets will no longer automatically renew and will expire and access to the Kerberos enabled service will fail.

The moral of the story is when depending on Kerberos for an application that has no NTLM fallback, make sure your users logout and login at least once per week. Actually, they should logout or lock their PCs whenever they leave them unattended. That’s just good security practice.

ShareThis

I have yet to see anything other than anecdotal evidence that changing your “ugly” permalinks to “pretty” permalinks has any significant positive effect on page ranking.  In fact, the reverse may be true, especially for established blogs with many indexed posts.

I have searched the web high and low and have yet to find any credible empirical study on the SEO effects of  permalink structure.   Most of the information I have garnered is purely opinion without much evidence to back it up.  It’s basically an “everyone’s doing it, so it must be right” attitude.  So, always rooting for the underdog, I’d like to put up a short defense of ugly permalinks.

1) Ugly permalinks are short and based at the root of the domain.

Custom permalinks are available in many formats, however, some defaults are offered.  Of the defaults, one of the more popular ones is the “Day and Name” permalink format: http://www.yourdomain.com/2008/07/04/sample-post/.  This URL is built using the /%year%/%monthnum%/%day%/%postname%/ tags.  Unlike the ugly permalink, this URL is three levels down from the root.  It is a bit long and it contains numbers that have no real meaning in relation to the post’s content.

Long URLs can appear as random keywords to the Google search bot unless the post title is very carefully crafted.  Google will penalize you for excessively long and random appearing URLs.  Don’t let your URLs look “spammy.”

While this popular custom URL format isn’t inherently spammy, consider the post: http://www.yourdomain.com/2008/07/04/if-i-have-to-listen-to-my-mother-in-law-complain-one-more-time/.  When reading it, it makes sense, but to a search bot, it really doesn’t contain any useful keywords.  I think with that post, the ugly permalink of: http://www.yourdomain.com/?p=123 is more than sufficient.

2) Ugly permalinks offer an absolutely unique post id.

One of the major advantages of ugly permalinks is that they ensure the post title doesn’t have to be unique.  For most people, this is not an issue, but consider the potential problem if you have multiple authors on your blog.  It is not beyond the realm of possibilities that your authors will try to create posts with duplicate titles.  The use of ugly permalinks make this a non-issue.

On the question of duplicates, one thing I haven’t been able to ascertain is whether using ugly permalinks can help eliminate duplicate content issues.  With the exception of data added after a trailing “/” as in ?p=223/xxx, no other invalid URL will return a page with ugly permalinks.  All invalid requests return a “Sorry, no posts matched your criteria” message.  With the custom URLs I have tested, the behavior is somewhat different.  It seems that any characters added after, or removed before the post name will redirect back to the post or the home page.  I’m undecided if this is the behavior I want, especially when trying to eliminate duplicates whenever possible.

I’m not sure how search bots interpret this.  Is this seen as duplicate content if someone links to you with an invalid URL?  I need to do some additional research to determine exactly how this situation is handled.

3) Ugly permalinks are immune from changes in category or post titles.

Many people use /%category%/%postname%/ format.  This can be a real nightmare if you ever decide to change your category names or structure.  All your indexed content at you favorite search engine is invalidated.  You can certainly use a redirection plugin, but that’s a real pain if you have many posts.

Post title edits, category changes, etc., do not affect ugly permalinks in the least.

4) Nobody cares about the URL anyway.

Who cares what the URL contains?  Most people find a site from a search engine or web link.  While it is probably somewhat more difficult to remember  http://www.yourdomain.com/?p=234 than http://www.yourdomain.com/my-receipe-for-bundt-cake/, who really want’s to type that in anyways?  It is much easier to bookmark the original link, or just go back to Google and google it again.

I have opted, at least for the time being, to stick with my ugly permalinks.  Unless someone can prove to me pretty permalinks have a significant SEO effect, the ugly ones seem just fine.  Your ranking is not about what’s in your URL, it’s about what’s in your post and what other sites think about your posts.  Stop worrying about permalinks and create better content that people want to link to.  That’s how page rank is built.

If I’m full of baloney please educate me as I don’t want to be the last person left using the uglies.

- A permalink heretic.

ShareThis