Monthly Archives: September 2009

Setting up FQDN viewable on Server

Posted by Jim on September 17, 2009
SharePoint / 4 Comments

PostBackISharePoint Server Farm Settings

When you use the fully qualified domain name (FQDN) or a custom host header to browse a local Web site that is hosted on a computer that is running Microsoft Internet Information Services (IIS) 5.1 or IIS 6, or 7 you may receive an error message that resembles the following on the farm server ………………… :

HTTP 401.1 – Unauthorized: Logon Failed


1)      Setting up Server Loopback for FQDN in SharePoint Site:

Must enable the Loopback in the DREC directory. To work around this issue, set the DisableStrictNameChecking registry entry to 1. For more information about how to do this, click the following article number to view the article in the Microsoft knowledge Base:
281308  ( ) Connecting to SMB share on a Windows 2000-based computer or a Windows Server 2003-based computer may not work with an alias name

Then, use one of the following methods, as appropriate for your situation.

Method 1: Specify host names
We recommend that you use this method.
To specify the host names that are mapped to the loopback address and can connect to Web sites on your computer, follow these steps:

  • Click Start, click Run, type regedit, and then click OK.
    • In Registry Editor, locate and then click the following registry key:
    • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0
    • Right-click MSV1_0, point to New, and then click Multi-String Value.
    • Type BackConnectionHostNames, and then press ENTER.
    • Right-click BackConnectionHostNames, and then click Modify.
    • In the Value data box, type the host name or the host names for the sites that are on the local computer, and then click OK.
    • Quit Registry Editor, and then restart the IISAdmin service.
  • Method 2: Disable the loopback check
    • Follow these steps:
    • Click Start, click Run, type regedit, and then click OK.
    • In Registry Editor, locate and then click the following registry key:
    • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
    • Right-click Lsa, point to New, and then click DWORD Value.
    • Type DisableLoopbackCheck, and then press ENTER.
    • Right-click DisableLoopbackCheck, and then click Modify.
    • In the Value data box, type 1, and then click OK.
    • Quit Registry Editor, and then restart your computer.


2)     Must add the FQDN to the HOST Record in Win32: To see your domain on our system before a DNS change takes effect, either:

1) Edit your hosts file on your PC. If you are using Windows, use “Start”, “Find”, “Files and Folders” to find a file in your windows directory (or WINNT\system32\drivers\etc) called “hosts”. Verify that the file is not “read only” by right clicking it, and choosing it’s Properties. Then open the file for editing with Notepad. There should already be an entry for “local host”. Follow that format when you insert your domain and our IP.

On Windows98 and Windows95, the order may be ‘hostname’ then ‘IP address’. On Windows2000 and Windows ME, the order is ‘IP address’ then ‘hostname’ localhost,

Then save this altered hosts file and close notepad. Make sure Windows did not silently save the file as “hosts.sam”. The filename has to be “hosts”. You may also need to reboot for the change to take effect. Next time you try to go to “”, your browser will try to find that domain at the corresponding IP instead of looking up the IP through DNS.

Mac OS 9’s hosts file format is based on RFC-1035. Mac OS 9 keeps its HOSTS file in the Preferences folder under the System folder. Edit this file and add a line for each host that you would like to map an IP to:

To find the hosts file in OS X’s graphical interface: 

  1. Open Finder.
  2. In the Go menu, select “Go to Folder”
  3. Type /etc for the folder name.
  4. In the list of files that appears, you should find hosts. Double click it to open it in a text editor.
  5. As in the earlier examples, the format of the file is: “”.

On Unix-based systems, as well as OS X’s terminal, you can find the hosts file at /etc/hosts. 

3)      Must add the FQDN to the Security Intranet setting as a trusted site:


To work around this behavior, each user must add * or the appropriate IP address range to the Local Intranet Sites dialog box:

  1. In Internet Explorer, click Tools, and then click Internet Options.
  2. On the Security tab, click Local intranet, and then click Sites.
  3. Click Advanced, and then type: * or an IP address range (for example, 157.54.100-200.*) in the Add this Web site to the zone box, where is your company and top-level domain names.
  4. Click Add, click OK, click OK, and then click OK again to close the Internet Options dialog box.
  5. Restart the computer.

These three steps should allow you to see site collections and SSP administration controll pannels from any server in the Farm.

Types of SharePoint Development Environments

Posted by Jim on September 11, 2009
SharePoint / 1 Comment

SPDevelopmentPart 1:

This is a short paper on known best practice for SharePoint 2007 development environments. This paper will pull to gather many sources to provide a general  overview of  reasonably acceptable formats and methods for establishing and maintaining a dependable development environment for working with SharePoint 2007 and soon to be release continuation “ 2010”. Although much has been written about developing  in a SharePoint environment, it is still unclear to many  IT professional what is really required for a development environment and when and how to create such environments. In fact it’s amazing to find how many insiders in the SharePoint world (administrators, developers) still are unsure on when a development environment is required.

For example do you need a Test or Dev environment to test permissions? What about capabilities and connectivity of web parts and data catalogs? I hear this question asked over and over –  when IT Departments prepare for deployments of SharePoint Solutions and even in active SharePoint deployments …. How will we manage a Development environment? Unfortunately, that is the wrong question to be asking first. The right question will always lay in the systems requirements of the SharePoint solution. Or as I ask, what are you planning to do with this thing called “SharePoint”?

Of course at the root of the issue is the simple requirement to protect the vital SharePoint resource and cost or recover to the organization after deployment while enabling the best utilization of the investments capabilities i.e. coding and enabling a full third tier of application development. I know in writing this most or all that probably that read it will have faced the woes and worries of down time and recovering production systems and are aware of the dangers of development in a production environment for enterprise class systems. So the real question is when does an organization adopting a SharePoint solution need to create a testing, staging or development environment and support the associated cost of such systems.  

When looking at five significant articles from reputable sources on “Best Practice” for SharePoint Development Environments, one thing clearly jumps off the page …… “System requirements”.  There are now so many companies using such a variety of configurations of SharePoint that that it’s difficult to determine truly what is best practices. For example SharePoint 2007 and Project Server. The combinations of just this configuration alone could produce numerous environment requirements and we haven’t even started talking about all the other back end solution with 2007 WSS enabled capabilities and hooks into SharePoint.

Another thing that stands out clearly as well ..… there is no “real best practice. Almost all documentation starts off with the caveat “depending on the company and systems” you are going to have to create a method of development based on the requirements, skill and experience of your IT team.

Interesting I began asking this very base question about what was the proper development environment  seven years ago as I scrambled to deployment a SharePoint 2003 solution to develop application based data interfaces for a large corporate identity ….. And well my point is, I have been asking every since. Not just myself but every company I consulted with. I would always ask the same question time and time again. What and how do you do development in your SharePoint environment? I’ve worked for large Microsoft Certified companies as well as small Partners and seen a lot environments.

So here we are seven years later and I am still asking the same question? In fact I recently visited a large IT shop in Atlanta, Manhattan Associates, as a meet and greet to review there in-house SharePoint systems. I remember leaving the building with the SharePoint IT Manager and asking the final question I always do “Joe what are you guys doing for a development environment at Manhattan and Associates”. Joe grinned as if he saw that one coming and laughed. “We don’t have one he said. That would be a luxury. We just can afford that kind of system”. This is the most common answer I hear when I ask new clients or customers the “Development” question. And Joe and his company represented a very large and well established SharePoint system. But in reality they were not engaging in anything that today would be classed as true development which required the creation of a fully enabled development environment. Now having said that lets dig deeper into the history of SharePoint.

Over the years I have seen a number of SharePoint installation and in reading the literature I think most will agree that SharePoint systems can be broken into two or maybe there categories.

1)      The first is the most common and may make up as much as 60 to 70 % of deployments in the real world. It’s a simple two to five server environment serving as a content management system, or a portal for the hub of corporate activity. No real application development is used and web parts are bought from the common vendors or developed for minimal use internally or through development vendors.


2)      The second is a far less common environment. One that supports a small farm cluster but by delineation is one where SharePoint has become the backbone and workhorse of a .NET shop or team of developers. In this environment many internal legacy systems are built, customized and run on the .Net platform which makes integration a vital part of the tools capabilities and utilization.


It’s important to delineate the two types of shops because the need for and set up of a  development environment is obtusely different as are the cost associated with each.  On the one hand, database catalogs and standard concepts of document handling, workgroups and calendar activity are being used as the center hub of the systems requirements. Customization is keep to a minimum and if any customization occurs, it fold under what Erric Charran described in his MSDN article dated April 2007 and published by Microsoft Corporation as Artifact Development.

Artifact development.

“By definition Artifact development is described in the article attached APPENDIX V, as utilization of the basic constructs of a SharePoint system such as “The development of items relating to the look and feel of a SharePoint site often relate directly to the development of items such as master pages and style sheets. These objects are considered artifacts in that they are not typically compiled and deployed as assemblies. These artifacts are characterized as content items that fit into the SharePoint site structure and that are applied at run time for the SharePoint Server site. The primary tool to create and manage these artifacts is Microsoft Office SharePoint Designer 2007. While Visual Studio has capabilities to assist developers in the creation and modification of these items, Office SharePoint Designer has new design-time tools and capabilities to help in the authoring and rendering of the artifacts so that their appearance during design time is extremely similar with the way the items will look after they are published and deployed.”

Taken from the Eric Charran, Publication dated April 2007 listed in the MSDN library by Microsoft Corporation. Full article attached in Appendix V.


And by its very nature is obvious that this Artifact Environment requires very little development and testing.In fact a properly structures and pool isolated site collection on the Production server might well server as all the basic Development environment that this company would ever need. Or maybe a set of virtuals and is about as extensive as the development environment really needs to be.

The second are of concentration called “Assembly Development” and again taken from the Eric Charran, Publication dated April 2007 listed in the MSDN library by Microsoft Corporation.

Assembly Development

“Assembly development for SharePoint Server is similar to traditional application development. In this branch of solution development, developers use Visual Studio 2005 to create various assemblies that are registered with the SharePoint Server Web application (and alternatively placed into the global assembly cache). These assemblies function as an extension to a Web application. Assemblies can take the form of Web Parts (essentially, ASP.NET 2.0 Web Parts) or other shared libraries that can service other assemblies. Assembly development encompasses solutions built using the Visual Studio 2005 Extensions for Windows SharePoint Services and includes custom list definitions, site definitions, and a specific SharePoint Web Part project type. For more information about the Visual Studio 2005 Extensions for Windows SharePoint Services, see the download for Windows SharePoint Services 3.0 Tools: Visual Studio 2005 Extensions [ ] .

Assembly development for SharePoint Server is directly compatible with traditional models of team development. Recently, team development for the Microsoft .NET Framework and other Microsoft technologies has migrated toward a model that supports collaboration and development by using isolated development environments. Developer code changes are combined through a common source control repository and build process. For more information about the team models for software development, see Microsoft Solutions Framework Team Model and Team System [ ] . “

Taken from the Eric Charran, Pu8blication dated April 2007 listed in the MSDN library by Microsoft Corporation. Full article attached in Appendix V.


Conclusion: – Part 2

James R. Odom
Sr. Consultant
Certified SharePoint Consultant, MCTS Development, Microsoft Corporation
Publication date: October 01, 2009

White Paper