Friday, March 30, 2007

Visual Studio 2005: Display Line Numbers Globally

Tools > Options > Text Editor > All Languages > Text Editor > Display > Check Line Numbers

Visual Studio 2005: Error: Setup Failed


Setup Failed


The failed setup issue was caused by latency on the network. The setup files were located on a remote, mapped network drive.

To sucessfully install Visual Studio, perform the following steps:
* Clear the temp folder.
* Start > Run > %Temp% > Delete files.
* Copy the setup files locally.
* Run setup.exe.

Thursday, March 29, 2007

SharePoint V2: Error: HTTP 404: File Not Found Internet Explorer


* Service Unavailable
* HTTP 404: File Not Found Internet Explorer.

After installing Macromedia RoboHelp to a SharePoint Portal Server 2003 web server, the existing SharePoint portals were returning the "Service Unavailable" error. RoboHelp was deinstalled from the server. Now, attempts to hit the SharePoint portals from Internet Explorer were behaving oddly. Using the FQDN (e.g. http://portalname.domain.com) in the URL was resulting in a 404 error. However, it was possible to hit the portal sites using the IP address and manually typing default.aspx (e.g.


* Backup IIS Metabase:
IIS Manager > Right Click the IIS Server Node > All Tasks > Backup/Restore Configuration > Create Backup

* Compare Metabase Configurations:
C:\Windows\System32\inetsrv\history > Locate the current metabase xml file and the most recent, valid one prior to the faulty installation attempt.

In this particular case we used an xml compare tool and identified that the current IIS Metabase had been corrupted by the faulty Robohelp installation. We found that the web services section of the current IIS Metabase was missing these entries below, preventing SharePoint from processing the HTTP requests.

* 1,C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\60\isapi\owssvr.dll,0,Windows SharePoint Services,Windows SharePoint Services
* 1,C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\60\isapi\shtml.dll,0,Windows SharePoint Services,Windows SharePoint Services
* 1,C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\60\isapi\_vti_adm\admin.dll,0,Windows SharePoint Services,Windows SharePoint Services
* 1,C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\60\isapi\_vti_aut\author.dll,0,Windows SharePoint Services,Windows SharePoint Services

* Restore a Valid Metabase Configuration:
IIS Manager > Right Click the IIS Server Node > All Tasks > Backup/Restore Configuration > Highlight valid backup prior to faulty installation > Restore

* Validate:
After restoring a valid IIS Metabase backup, the SharePoint portals were functioning properly. They became accessible both through FQDN or IP Address.


* It is not recommended to use this solution every time an IE 404 error is encountered. There are several possible causes for the IE 404 error. This example is one scenario where an IE 404 error was encountered and IIS Metabase restore happened to be the solution. It is recommended to fully investigate an issue and taking proper precautions before applying this solution.

* It is a good idea to take IIS Metabase backups prior to installing software to a web server that would alter the IIS configuration. Having the IIS Metabase backup handy provides an extra safety net in the event that a configuration needs to be rolled back.

Wednesday, March 21, 2007

SharePoint V3: Configuring Custom NewForm.aspx, EditForm.aspx, DispForm.aspx

NewForm.aspx, EditForm.aspx, DispForm.aspx represent the web pages that the SharePoint user sees when they click the New , Edit, or Display actions from a custom list web part tool bar, or from an "Linked to Edit Item" drop down.

In SharePoint deployments, it is fairly common to have a requirement to override these pages with custom pages. You would want to do this when you want to hide fields from a user, or when you want to enhance the appearance of the page for the user.

One example of where I needed to do this is on a custom list where I had configured a SharePoint Designer workflow. The workflow was fairly complex and I had configured some extra fields on the custom list to facilitate the workflow. I didn't want the users to see these extra fields when they were creating, editing, or viewing items in the list so I had to hide these fields.

Here are the steps to configuring custom NewForm.aspx on an existing custom list. These steps may also be used to configure custom EditForm.aspx or DispForm.aspx.

* SharePoint Designer > File > Open Site
* Expand the lists folder
* Expand the custom list that you are modifying
* Double click NewForm.aspx to open it
* File > Save As
* Name the custom list something unique (do not overwrite the default NewForm.aspx) e.g.
* NewFormCustom.aspx
* You will see a generic SharePoint control in the center of the page with column 1, column 2, column 3
* Right click the SharePoint control that is in the center of the NewFormCustom.aspx page, Cut to remove it from the pageInsert > SharePoint Controls > Custom List Form
* Right click within the Custom List Form SharePoint control to invoke the menu.
* Modify the Custom List Form SharePoint control.
* File, Save
* Right click the custom list container > Properties
* List Properties > Supporting Files Tab > Configure this tab accordingly, pointing NewItemForm to NewFormCustom.aspx
* Apply, OK
* File, Save

If you need the revert back to the original NewForm.aspx, you can open the list properties from SharePoint Designer, navigate to the Supporting Files tab, and point the NewItemForm property back to NewForm.aspx. Furthermore, if the requirements change, the original NewForm.aspx is still in tact and you have the option to create additional, custom NewForm.aspx pages.

Words of caution about working with the NewForm.aspx, EditForm.aspx, and DispForm.aspx:
* Always create a web part template of the custom list or document library as a backup, before making changes
* If the custom list or document library has workflow, take the additional step of creating a site template or backup the site collection entirely using stsadm
* Never rename the default NewForm.aspx, EditForm.aspx, or DispForm.aspx pages. This will corrupt the custom list. When you click on Edit Item you will receive an error, "Invalid URL." Instead use the steps above.
* After switching to the custom form, attachments are no longer supported on the custom list. If you try to add an attachment you will get an error, "This form was customized not working with attachment."


Microsoft published a knowledge base article addressing the attachment issue:

Microsoft KB 953271:
Error message when you try to attach a file in a custom form on the Web site in Windows SharePoint Services 3.0: “This form was customized not working with attachment"

Friday, March 16, 2007

SQL Server: Query Server Name, Edition, Product Level, Product Version

Run this query for the SQL Server name, edition, product level, and product version:


Refer to Microsoft KB
321185 titled, "How to identify your SQL Server version and edition" to identify which service pack corresponds with the product version number.

SharePoint V3: Subtle Behaviors with Custom Site Tab and Site Column Groups

First one has to do with custom site templates (.stp). Starting from a site, if you navigate to Site Actions > Create > Sites and Workspaces and you look at the Template Selection section you will always see Collaboration, Meetings, Enterprise, Publishing tabs. If you have created at least one custom site template (.stp) then you will see a Custom tab as well. If you navigate to the site template gallery /_catalogs/wt/forms/common.aspx and delete your custom site templates (don't delete the forms folder) then you were to go back to the Create Site page you will see that the Custom tab has disappeared.

A similar behavior exists within the Site Column. From the home page if you navigate to Site Actions > Site Settings > Modify All Site Settings > Site Column Gallery. MOSS 2007 allows you to create new site columns groups when you create new site columns. You may also add a new site column to an existing group. The subtle behavior here is that if you move all of the site columns out of one particular site column group, then that group name will disappear. You need at least one site column to be added to the site column group in order for the group name to exist.

Wednesday, March 14, 2007

SharePoint V3: Master Page Not Inherited By Non-Publishing Sites


We encountered an issue where we had deployed a custom master page but not all of the sites in the site collection were recognizing the changes.

First, a little background on what we had done:
We opened the home page (a publishing site) of a SharePoint V3 site collection in SharePoint Designer. Next we copied the default.master and renamed the copy to custom.master. In custom.master we changed the logo in the header of the page to a custom image. Next, we opened the site collection in Internet Explorer and in Site Settings > Look and Feel > Master Page changed the Site Master page to custom.master. We clicked OK to save changes and reviewed the top level site. The header logo was updated. Next we reviewed another top level site, but these sites did not have the new header logo.


Site Settings > Look and Feel > Master PageSite Master Page:
* Select Specify a master page to be used by this site and all sites that inherit from it.
* Select custom.master from the drop down selection.
* Check off Reset all subsites to inherit this Site Master Page Setting

Site Settings > Look and Feel > System Master PageSite Master Page:
* Select Specify a master page to be used by this site and all sites that inherit from it.
* Select custom.master from the drop down selection.
* Check off Reset all subsites to inherit this Site Master Page Setting

The way this works is that the "Master Page" setting is used by publishing sites. The "System Master Page" is used by non-publishing sites. The terminology used in SharePoint V3 and SharePoint Designer are not intuitive, although the descriptions on the Site Settings > Look and Feel > Master Page do help a bit.

Thanks Marc Anderson for taking the time to read the small print and explain this out loud.

For further explanation, refer to Kathy's blog post,
SharePoint Designer Snippets: Working with Master Pages, which helps clarify any confusion regarding this topic.

To expand on this blog post, I think of the Site Settings > Look and Feel > Master Page like this:

* Master Page = Custom Master Page = Publishing Sites
* System Master Page = Default Master Page = Non-Publishing Sites

SharePoint Designer Workflow: It's Just a Facilitator

SharePoint Designer workflow in general is best used as a facilitator of actions that make up a business process and it does not work well for automating or enforcing an entire, complex, human process. What I mean is that SharePoint Designer workflow is best used to automate certain actions that occur within a business process like assign a status of something, or email something, or copy something but its not going to replace human decision making and its not going to perform the entire business process for you.

Say, for example, that Company ABC's IT team is supporting 100 employees through email exchanges. When an employee has an issue, they email an IT distribution list then the IT staff responds to the issue. The IT team is finding that they are struggling to keep track of the support requests. They are considering using SharePoint to track support requests.

A solution to this business problem may be to use SharePoint to structure the metadata about support requests and use workflow to automate actions that occur during the process. Create a SharePoint custom list to track support requests with request id, requestor email, status, title, description, solution fields, and then use SharePoint Designer workflow to perform the following:

* Automatically generate request id for new support requests
* Automatically build and send email the requestor when status of items is changed

SharePoint Designer should not be used to implement rigid rules that contain deep branchings for how the support requests are resolved. You do not want to attempt to create a workflow that predicts and solves the support requests that you are tracking within SharePoint. Thining through and resolving support requests is a complex human process and it scales beyond practical limits of SharePoint Designer workflow.

Workflow can certainly improve processes, and it can simplify tasks that a person performs during a business process, such as the example above....just don't expect workflow to do somebody's job for them.

Friday, March 02, 2007

SharePoint V3: Error: Excel Services: Access Denied

Error: "Access Denied. You do not have permissions to open this file on Excel Services. Make sure that the file is in an Excel Services trusted location and that you have access to the file."

The Excel Services is properly enabled and Excel Services trusted file locations have been properly configured in SharePoint Central Admin. Your user account has access to the Office SharePoint Server 2007 document library that you are trying to publish an Excel workbook to, however, you receive an Access Denied error when attempting to publish an Excel 12 workbook to the document library.

Open the Shared Services Admin Site

Central Admin > Application Management > Create or Configure this Farm's Shared Services > SSP > Open Shared Services Admin Site
Set the Unattended Service Account

Shared Services Admin > Excel Services Settings > Edit Excel Services Settings > External Data > Unattended Service Account

Thursday, March 01, 2007

SharePoint Intranets, Evolving Beyond Department Sites

I admire software application, user interfaces that are built around a purpose. The most popular business application in the world, Microsoft Outlook is a great example. It provides messaging, task management, calendar management, and more. The buttons and menus are organized in a manner that is suitable for sending email or tracking a task. The user interface is intuitive, easy to use, and makes sense.

I think a trend for SharePoint intranet deployments is that they will include designs which are less influenced by content categorization and taxonomy and more influenced by functionality.

When you think of various SharePoint intranets that are being used in businesses today, you might struggle to draw a correlation between the user interface and the functionality. I think that has a lot to do with the fact that implementers are responsible for coming up with a design, a context. I think a common habit among implementers has been to design the applications around organizational structure of the company. When SharePoint sites first started popping up, they weren't much more than web folders for documents, and their main "purpose" was sharing documents as an alternative to a file share. So, the user interface design took on a shape similar to how documents are categorized in a folder share. I think that categorizing documents by department resulted in a trend of SharePoint portals that have a department based design.

I think a challenge now is to recognize where SharePoint came from, that department site designs are out of date, and applications built on it are no longer just HTTP enabled versions of Windows Explorer. We are now dealing with real business applications with real (and custom) purpose. User interfaces need to evolve accordingly.

If you've spent a significant amount of time performing a job function as a SharePoint portal user, in an environment that is organized by department you may have come to the realization like I have that organizing collaborative or actionable content and information according to department doesn't make a lot of sense all the time.

One way to evaluate this is to think about the audience (I mean audience in the general sense) the sites's information is addressed to and what the audience is supposed do with the information. You might find that when the audience doesn't have to "do" anything with the information other than consume it then it might work well in a department site. For example, an announcement is posted to an HR department web site that there is a new employee handbook. The audience simply consumes this information. They are not expected to collaborate and edit the handbook. In this example the department site probably works ok.

Its really when you start getting into information that you are working with when department sites start to fall apart. Collaboration using list items, documents, forms, and workflow occurs around a subject, not around a department. So why try to categorize the information you use to collaborate on, into a department? A SharePoint user who is performing a function doesn't care "who" owns the content any more then they care when it was created. It would make more sense to me if the user interface design promoted what users are actually doing in the system as opposed to who owns the subject matter that the user is working with.

Effective Security Model for SharePoint

Creating an effective, scalable security model and governance plan for a SharePoint implementation is one of the most important and intricate aspects of a SharePoint deployment. Developing a security model usually requires cooperation from from a lot of different people. It requires communication with the business groups for articulating the security requirements of their content, the security people for communicating the policies (such as Sarbanes Oxley), interpreters of these requirements for designing a consistent roles based structure and naming convention (in AD and SharePoint) and IT staff responsible for managing the provisioning and deprovisioning.

Much like the user interface of SharePoint is an open canvas, the security model offers lots of room for creativity, though the efforts are mostly transparent to the end users. When designing a security model, I like to thing about things like what size is the user base, what is the organizational structure of the company, how do the business units interact with each other, what are the security policies in the company, how strict must the security on the content be, is the IT staff willing to accept the responsibilities, etc..

As a rule of thumb (with exceptions of course), I don't create SharePoint users, instead I create SharePoint groups and corresponding AD groups. I like to manage the memberships exclusively in AD. Another thing I try to avoid doing is creating roles based solely on org charts. If an organization is collaborative enough that they are implementing SharePoint, then chances people are interacting outside of their immediate department anyways. Most workspaces and content are custom and besides; departments change and reorganizations happen.

There is a significant effort that goes with keeping the security model in good shape. Limit SharePoint security to roles based groups, keep all of the group membership management in AD, and have a consistent organized pattern and naming convention. When that is all set, spend a some time developing the following two reports:

  • A report that shows Sharepoint Site, SharePoint group names, access levels
  • A report that shows AD groups, member names, and email addresses, nested groups and their members
...then you have an effective security model.

Blog Archive