Web Log

Today while developing an ASP.NET application using AJAX to display the Search Result, I encountered a weird issue. My aspx p age contain a Repeater control with ItemTemplate to display free flow data in HTML Table .  Issue What seems to happen though, is that one or two rows in the loaded table, will have its data offset at a random column.   You can find the details of issue in following articles: http://stackoverflow.com/questions/7267014/ie9-table-has-random-rows-which-are-offset-at-random-columns http://social.msdn.microsoft.com/Forums/en-AU/iewebdevelopment/thread/28d78780-c95c-4c35-9695-237ebb912d90 Resolution The problem was with extra white space between td nodes causing IE9 render a dynamically generated table incorrectly, in my case to misalign a cell within a table.  Same code rendered perfectly fine in IE6, IE7, IE8, FireFox 4, Chrome 10, but not IE9.  Try one of the following Adding to the head element [meta http-equiv="X-UA-Comp

Open up command prompt and navigate to C:\Inetpub\AdminScripts. Then type: cscript.exe adsutil.vbs get w3svc/anonymoususerpass If everything goes well, you will see the following with the password in ***** format: C:\Inetpub\AdminScripts>cscript.exe adsutil.vbs get w3svc/anonymoususerpas Microsoft (R) Windows Script Host Version 5.6 Copyright (C) Microsoft Corporation 1996-2001. All rights reserved. anonymoususerpass : (STRING) "**********" To display the IUSR and IWAM account passwords in cleartext, you need to open C:\Inetpub\AdminScripts and edit Adsutil.vbs in Notepad. Find this line: If (Attribute = True) Then IsSecureProperty = True Else IsSecureProperty = False End If and change it to: If (Attribute = True) Then IsSecureProperty = False Else IsSecureProperty = False End If Now run the script commands above again and you will see the passwords in clear text. Of course, please make

When creating Workflows in SharePoint, you might have encountered issue when workflow recursively call itself and  tell the workflow to run automatically when an item is updated [approved], then because the workflow is updating the item its goes and calls itself again! This is known as recursive workflows, commonly known as an "infinite looping" in a workflow. To avoid this issue we just need to a dd a condition to the Workflow and only update list or document library item on certain condition. I found an interesting Microsoft article  Run a workflow when a specific field changes Also there is a video which also s how how the conditions prevent recursive workflows.

By default, categories are shown in the legend to identify each value. If you have labeled the pie chart using category labels, you may want show percentages in the legend. To display percentage values as labels on a pie chart Type  #PERCENT  for the  Label data  option. (Optional) To specify how many decimal places the label shows, type "#PERCENT{P n }" where  n  is the number of decimal places to display. For example, to display no decimal places, type "#PERCENT{P0}". Click here  for Microsoft Technet Article for more details.

Recently I came across an issue where ‘Alert Me’ emails originated from SharePoint environment are getting garbled and reaching the customers in following format. Resolution   After troubleshooting it was found that somehow recent patch on Exchange Server was adding a line break in Internet Email header messing up the Header itself, which was garbling the Email body and it was showing something like this.  On  analyzing multiple garbled email headers and comparing them to working email header it was found that these garbled messages were missing the “Reply To” address. Setting up the ‘Reply To’ address in SharePoint Admin for the Farm fixed the issue. Note that this issue was only with ‘Alert Me’ email relaying outside the company to extranet users, within companies Email Addresses there seems to be no issue.  Also a point to note that this entry was missing for last 2 years and we never faced this issue, nothing was changed on SharePoint server when this issue was bro

Being a SharePoint Administrator you might have come across a requirement where it is required to setup a SharePoint found in ‘Active Directory account creation mode’. Active Directory account creation mode  this mode is used by Internet Service Providers to create unique user accounts for customers in Microsoft Active Directory service. These accounts can then be assigned to groups in Windows SharePoint Services to grant customers the appropriate level of access. After successful setup when everything was working fine than we noticed that we are not able to create any user in the Active Directory. We were getting following error The specified domain either does not exist or could not be contacted. (Exception from HRESULT: 0x8007054B) After weeks of troubleshooting and looking into every aspect of AD access issue, SharePoint ULS Logs we came across a Microsoft article http://support.microsoft.com/kb/828813 which state: This problem may also occur if you specif

Validation of viewstate MAC failed. If this application is hosted by a Web Farm or cluster, ensure that configuration specifies the same validationKey and validation algorithm. AutoGenerate cannot be used in a cluster. You might have come across this error, if you are a .net developer, using ViewState and deployed application in Web Farm. On deploying asp.net web app into a web farm environment, each web servers machine.config or web.config must specify the same key used for encrypting the view state. Remember the view state is encrypted for security reasons and each machine.config on each web server will have a different key so they must all be the same.  Best way is to add a machineKey element into each of the web server's web.config and define the same keys and algorithm. The machineKey goes under the System.web node. <"machineKey validation="SHA1" validationKey="A1B2C3D4E5F6F6E5D4C3B2A1A1B2C3D4E5F6F6E5D4C3B2A1A1B2C3D4 E5F6F6E5D4C3B2A1A1B2C3D

All assemblies provisioned by the solution will be deployed to the Global Assembly Cache (GAC) of the target web server which might not always be desirable/doable. There are a couple of ways of how to change the DeploymentTarget to the bin directory of the target Web Application. One way of changing the WSPBuilder’s default behavior is using the WSPBuilder.exe.config file. Changing the value of the DeploymentTarget settings would be applied globally instead on a per-project basis. Every WSP you build  on your development machine using WSPBuilder would be built with the DeploymentTarget set to WebApplication. While such approach would do the job, it would take away the flexibility that WSPBuilder is supposed to provide. Another way of overriding the default setting is using the command line version from either MSBuild or post-build actions. Using the –DeploymentTarget switch you could set the DeploymentTarget to WebApplication. You are very likely to use this approach if you’re a

To display full errors and the stack trace of the error, you need to modify the web.config file for the Web Application which SharePoint is running on. There are a number of web.config files required to configure various components of SharePoint. See notes below for more information about modifying the web.config file to display errors. Enable Custom Errors : Set the customErrors mode to “Off” Find: customErrors mode=”On”  Change To:  customErrors mode=”Off” Enable the Call Stack Trace : Set the CallStack value of the SafeMode element to “true” Find: SafeMode … CallStack=”false” Change To:  SafeMode … CallStack=”true” Enable Debugging Mode : Set batch and debug to “true” Find: compilation batch=”false” debug=”false” Change To:  compilation batch=”true” debug=”true” Enable the ASP.NET tracing feature : Include the following line in the element of the web.config file. trace enabled=”true” pageOutput=”true”

If you are debugging a ASP.NET web application which is hosted on IIS, you need to attach the particular worker process in Visual Studio to start debugging. To Attach a process we can go to  Tools > Attach Process  or use shortcut key  Ctrl +P . The process window will show the  worker process (w3wp.exe)  which is currently running on IIS. You need to select the process and click on attach button to start the debugging. Problem starts when you have  multiple worker process running on IIS .  If you have multiple sites hosted on IIS and each site having their own application pool then you will see the list of all worker process in the Process Attach window. Here  you need to identify the particular worker process which is associated with your application pool. Identify Worker Process in IIS 6.0 • Start > Run > Cmd • Go To  Windows > System32 • Run  cscript iisapp.vbs • You will get the list of  Running Worker ProcessID  and the  Application Pool Name . So, here