Sign In
Share this page on Facebook Share this page on Linkedin Share this page on Twitter Email a link to this page
  • Jun.25.2012

    ​This is a problem that has been plaguing me for years.  When you access a SharePoint site with a fully qualified domain name (FQDN) such as, you get repeatedly prompted for credentials.  A FQDN has periods in the name, as in the URL above.  Since we do a lot of work with Extranets, we typically use SSL (secure https sites) and FQDNs on our sites, since they will be accessed externally as well as internally.

    The first fix is in the browser itself.  In order to have the browser pass your logged on credentials to the server, it needs to be in the Intranet zone.  FQDNs are automatically considered to be Internet sites by the browser.  To change this do the following:

    1. From the browser Tools menu, select Internet Options
    2.  Go to the Security tab
    3. Select Local intranet
    4. Click Sites
    5. Click Advanced
    6. Add the FQDN to the Websites list

    The above was the easy part, and applies to the browser.  However if your applications use WebDav, you still get prompted for credentials, even if you are already logged in with the correct credentials.  This will cause you grief with all the Office applications (Word, Excel, PowerPoint, InfoPath), opening a library in Explorer (so you can move files around easily), and many other situations.

    Our Systems Administrator and resident guru Wes found the appropriate changes needed to support this.  Basically you'll need to add a registry entry to each client computer, after which you should not be repeatedly prompted for credentials.

    1. From the Start-Run menu run RegEdit
    2. Navigate to the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\WebClient\Parameters path
    3. Right-click Parameters and create a New Multi-String Value
    4. Name it AuthForwardServerList
    5. Enter one or more FQDNs that you want the rule to apply to

    Note that you can also enter wildcards such as *, for both the Intranet zone browser settings and the WebDav support.

    Of course the ideal way to do both of these is by adding a Group Policy Preferences to your AD (which is what Wes did).

  • Jun.14.2012

    ​On June 14th I delivered a seminar at Microsoft on Creating Dynamic Web Sites with SharePoint Web Content Management.

    Microsoft SharePoint is a powerful platform for creating rich internet web sites that put you ahead of your competition. Many organizations are already familiar with SharePoint’s collaboration capabilities; in this seminar we demonstrated how you can leverage SharePoint Web Content Management capabilities to:

    • Allow business users to easily maintain content
    • Create dynamic sites with modern creative designs and branding
    • Keep customers engaged with social media
    • Create rich content including video and images
    • Customize your site to specific visitors
    • Provide a rich interactive user experience
    • Manage content from multiple sources
    • Decrease costs by leveraging SharePoint for your Internet, Extranet, Intranet and collaboration needs
    • Ensure a broader reach with sites that offer multilingual support, cross-browser and mobile functionality and W3C accessibility
    • Learn about search engine optimization and web analytics

    Showcasing some of the client sites Envision IT has built, we demonstrated WCM key features in SharePoint, some SEO optimization techniques and best practices, and use of Social Media. You can view the presentation by clicking the link below:

    Presentation - Create Dynamic Web Sites with SharePoint Web Content Management

  • Jun.11.2012

    ​Last week we wrapped up a very successful series of webinars that ran from April through to June.  The topic was Extranets, with a focus on our Envision IT Extranet User Manager Product.  We had more than 500 people register.

    You can see the full agenda for the webinar, along with the slide deck and a full video recording of the webinar, by visiting the Envision IT Extranet Webinar page.

  • Jun.03.2012

    ​While I've performed and spoken on SharePoint 2007 to 2010 upgrades for quite some time now, recently we have become involved in a number of large migration projects for corporate clients.  One of the bigger challenges in these upgrades has been identifying the features required for the sites in 2010, and determining a strategy for supporting them.

    When we are doing 2010 upgrades, we generally recommend taking a content database attach approach to the upgrade.  I'm not a fan on in place upgrades, due to the fact that we don't know the health of the 2007 farm, and we genreally don't want to bring that legacy of potential issues with us through the upgrade.  One of the main reasons for doing the upgrade (aside from getting to 2010) is to get a clean, well-built, and well-documented 2010 environment to work in, which means a fresh build.

    To determine the features needed, we will often do a the following PowerShell command to test the upgrade.

    Test-SPContentDatabase -name dbName -webapplication siteUrl

    This will generate the same upgrade error log as actually attaching the content database, and we can review that to determine the missing features.  When we are ready to actually attach the databse, we can do that with the following:

     Mount-SPContentDatabase -name dbName -webapplication siteUrl

    To review the errors and warnings from a number of content database attaches, do the following:

    1. Go to the C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\LOGS folder
    2. Copy the relevant Upgrade...-error.log files to an empty temp folder
    3. Use Visual Studio or SQL Management Studio to do a Find in Files of [ERROR] or [WARNING], and find all files.  This will give you an output of all the error or warning lines in all the error logs

    Once we have tested or performed the upgrade, the challenge is determining the features needed.  The upgrade error log simply reports the missing feature IDs, not what they actually are.  To determine the features themselves, we use one of two techniques.

    The first technique involves accessing the 2007 production farm.  We perform these steps:

    1. Go to the C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\FEATURES folder
    2. Use Visual Studio or SQL Management Studio to do a Find in Files of the desired feature ID
    3. Use the folder name to identify the feature name

    An alternative technique involves having a repository of all the WSP solution files used on the production farm.  With those perform the following:

    1. Copy the WSP files to a temp location
    2. Open a command prompt to that location
    3. Run rename *.wsp *.cab to rename all the WSP files to CAB files
    4. Open each CAB file and extract the contents to a sub-folder of the same name
    5. Use Visual Studio or SQL Management Studio to do a Find in Files of the desired feature ID
    6. Use the folder name to identify the feature name


Copyright ©2013 Peter Carson