We were moving an ASP.NET 2.0 application from IIS 6 to IIS 7 and we ran into a problem. The code in the global.asax Session_Start was not running. However, this code had been running fine in every environment (development, testing, production) in IIS 6. Through a lot of research and trial and error, we figured out a solution to the problem. I’m not sure the problem was necessarily with IIS 7 because we saw posts on the Internet of the same symptoms on IIS 6.0. It should be noted that when the code is executed within VS, it ran fine too.
Our standard has been to use the Web Deployment Project for creating the compiled output that is then copied to a IIS server. Our standard has also been to merge all outputs to a single assembly. When this is done, all compiled code is put into a single DLL. If you use the global.asax, there is file called App_global.asax.compiled that is used to tell the runtime engine to reference the single DLL for the global.asax code. It would appear that when you have your project compiled into a single DLL, this problem manifests itself.
Our solution was to change the way the code was to be compiled. Rather than merging all outputs to a single assembly, we set it to merge all pages and control outputs to a single assembly. Do so still creates the App_global.asax.compiled file, but instead the compilation of the global.asax code is into its own DLL (App_global.asax.dll). By doing this the code in the global.asax started working.
Monday, April 20, 2009
Thursday, April 9, 2009
Job hangs when running SSIS package
I had a SSIS package that I modified and put out onto a development server. When I ran the existing job, the job would hang. Based on troubleshooting, it would appear the package would not even begin to start. When the package was executed from the development PC, it ran fine. When remoted into the SQL Server and ran the package in BIDS, it ran fine. However, when we ran in a command line the command that was in the job step, it would produce the following error. Note that the package would in fact run though under this method.
The file name is not valid. The file name is a device or contains invalid characters.
It turns out the problem was the fact that the package used a configuration file and the config file specified the location of where the checkpoint file should be written. The config file on the server had the checkpoint file location as the developer’s workstation and not of the location for the development environment. Upon changing the config file, the job would then run the package successfully. It would appear that when this type of error is encounter in a job, the job would hang and not handle the exception correctly.
The file name is not valid. The file name is a device or contains invalid characters.
It turns out the problem was the fact that the package used a configuration file and the config file specified the location of where the checkpoint file should be written. The config file on the server had the checkpoint file location as the developer’s workstation and not of the location for the development environment. Upon changing the config file, the job would then run the package successfully. It would appear that when this type of error is encounter in a job, the job would hang and not handle the exception correctly.
Monday, March 30, 2009
Kerberos and SharePoint
Great link on Kerberos and SharePoint. Probably one of the best descriptions of how Kerberos really works.
http://www.sharepointjoel.com/Lists/Posts/Post.aspx?List=0cd1a63d%2D183c%2D4fc2%2D8320%2Dba5369008acb&ID=2
http://www.sharepointjoel.com/Lists/Posts/Post.aspx?List=0cd1a63d%2D183c%2D4fc2%2D8320%2Dba5369008acb&ID=2
Monday, January 12, 2009
Quickly adding data to SharePoint List
I was working on a SharePoint project where I needed to quickly add 100’s of list items to a list. The list was not your ordinary list. The list had the following column types.
Text
Person or Group (Show Name field)
Person or Group (Show Account)
Yes/No (default Yes)
Lookup (based on a “division” list)
This list was to store a list of approvers for a workflow application I was working on. The Person columns were used to get the Display Name and the account name of the approvers (keep in mind we use Active Directory for our user store). The Yes/No column indicated whether or not to email the user. And the Lookup column was for identifying what division the person worked for. When it came time to populate this list, the users did not want to have to type in 100’s of people into this list. So they asked me to put them in. Lucky me.
Since I’m lazy, I wanted a quick way of doing this. First, I thought about doing it programmatically, but again, I’m lazy. So, there had to be a better way. Why can’t I just use SharePoint’s native functionality? Please know that what I’m about to describe took me the better part of half a day to figure out. But once I had the process down, it only takes a few minutes to accomplish what I needed to do.
Step 1: Clean Data
The users gave me a spreadsheet of the people they wanted added. And if your users are like mine, the spreadsheet contains data that is not very conducive to “importing”. It is always dirty and never contains all the data you really need. Since I knew that I would be adding users that are in our Active Directory, I did tell them I needed to have a unique way of identifying people. Luckily, we store our employee numbers in Active Directory, therefore, I was able to bounce the list against AD to obtain the approvers’ Display Name and Account ID. Hopefully, you have similar environment where you can easily do this. Once I had the AD data I needed, I continued in Excel and removed duplicates and so forth. Tip: learn about Excel’s VLOOKUP function. Its great!
Step 2: Build an “Import Spreadsheet”
Once I had clean data to work with, I turned to how I was going to get the data into the SharePoint list. I knew the list had the following columns.
Title
DisplayName
Account
EmailBackup
Division
So I went into Excel and created a sheet that had the same column names, mapping the clean data accordingly. For the Title column, I just entered “Approver” for all the rows. For the EmailBackup column, the users indicated which approvers should get an email. Therefore, using some Excel functions (IF and LEN functions), I populated this column with either a value of “Yes” or a blank value. For the Division column, I had a value of the Division for the approvers I was importing. The key here is to make sure the value matches that of one in the list the defines the lookup column. Once done, I had what looked like a clean and complete Excel spreadsheet that matched my SharePoint list.
Step 3: Importing data into SharePoint
When you look at a list, you have under the Actions menu a option called Edit in Datasheet. This is the key to doing what I needed to do quickly. But there are some problems with doing this. To actually get your data from the Excel spreadsheet into the list, all you really have to do is copy all columns/rows from the spreadsheet and paste them into the Edit in Datasheet view. Simple, simple! But, because of the column types, this becomes very problematic. Most notably, the Person or Group column is the biggest problem! When you try to paste, you may get an error similar to the following.
Cannot paste the copied data due to data type mismatches or invalid data. Some source rows which would have created new rows contained invalid values in required fields. These rows were skipped.
Say what? Okay, to save a lot of Googling, what this really means is you have data that cannot be used. And as I already clued you into, the columns that are defined as People or Group are the problem. The reason is because of how the Edit in Datasheet view works with these columns. I don’t have the 100% accurate explanation of this, but it appears that SharePoint gets from its “user store” all possible users and puts them into a dropdown list. If you are in the Edit in Datasheet view and dropdown a Person or Group column, you will see what I mean. So, what is happening is you have users in your spreadsheet data that is not in the SharePoint “user store”. Hence, invalid data.
Step 4: Fixing the Invalid Data error
So, how do you fix this? Easy, return to Excel for a quick moment. Create a new column in your spreadsheet. Using the CONCATENATE function, append a semicolon onto the end of either the user Display Name or Account (keep in mind, this is the data I got from AD). Now that you have a list of users with a semicolon at the end, copy that column and return to SharePoint.
Go to the Site Settings of the site where your list is and go to People and Groups. Create a new group, naming it so that it sticks out like a sore thumb. Now, add users to this group. In the Users/Group textbox, do a paste. What should happen is everything you copied from the spreadsheet (users with an semicolon appended to the end) should have pasted. Uncheck the “Send email” option and click Ok. The group should be populated with all of the users. Great. Now, delete the group.
This is the magic operation to get Edit in Datasheet People or Group dropdown list populated with the values you need!
Step 5: Finally, Populating the List
Return to your list and change back into Edit in Datasheet mode. Now you should be able to copy and paste your Excel data directly into the Datasheet, without error. It is as simple as that!
Text
Person or Group (Show Name field)
Person or Group (Show Account)
Yes/No (default Yes)
Lookup (based on a “division” list)
This list was to store a list of approvers for a workflow application I was working on. The Person columns were used to get the Display Name and the account name of the approvers (keep in mind we use Active Directory for our user store). The Yes/No column indicated whether or not to email the user. And the Lookup column was for identifying what division the person worked for. When it came time to populate this list, the users did not want to have to type in 100’s of people into this list. So they asked me to put them in. Lucky me.
Since I’m lazy, I wanted a quick way of doing this. First, I thought about doing it programmatically, but again, I’m lazy. So, there had to be a better way. Why can’t I just use SharePoint’s native functionality? Please know that what I’m about to describe took me the better part of half a day to figure out. But once I had the process down, it only takes a few minutes to accomplish what I needed to do.
Step 1: Clean Data
The users gave me a spreadsheet of the people they wanted added. And if your users are like mine, the spreadsheet contains data that is not very conducive to “importing”. It is always dirty and never contains all the data you really need. Since I knew that I would be adding users that are in our Active Directory, I did tell them I needed to have a unique way of identifying people. Luckily, we store our employee numbers in Active Directory, therefore, I was able to bounce the list against AD to obtain the approvers’ Display Name and Account ID. Hopefully, you have similar environment where you can easily do this. Once I had the AD data I needed, I continued in Excel and removed duplicates and so forth. Tip: learn about Excel’s VLOOKUP function. Its great!
Step 2: Build an “Import Spreadsheet”
Once I had clean data to work with, I turned to how I was going to get the data into the SharePoint list. I knew the list had the following columns.
Title
DisplayName
Account
EmailBackup
Division
So I went into Excel and created a sheet that had the same column names, mapping the clean data accordingly. For the Title column, I just entered “Approver” for all the rows. For the EmailBackup column, the users indicated which approvers should get an email. Therefore, using some Excel functions (IF and LEN functions), I populated this column with either a value of “Yes” or a blank value. For the Division column, I had a value of the Division for the approvers I was importing. The key here is to make sure the value matches that of one in the list the defines the lookup column. Once done, I had what looked like a clean and complete Excel spreadsheet that matched my SharePoint list.
Step 3: Importing data into SharePoint
When you look at a list, you have under the Actions menu a option called Edit in Datasheet. This is the key to doing what I needed to do quickly. But there are some problems with doing this. To actually get your data from the Excel spreadsheet into the list, all you really have to do is copy all columns/rows from the spreadsheet and paste them into the Edit in Datasheet view. Simple, simple! But, because of the column types, this becomes very problematic. Most notably, the Person or Group column is the biggest problem! When you try to paste, you may get an error similar to the following.
Cannot paste the copied data due to data type mismatches or invalid data. Some source rows which would have created new rows contained invalid values in required fields. These rows were skipped.
Say what? Okay, to save a lot of Googling, what this really means is you have data that cannot be used. And as I already clued you into, the columns that are defined as People or Group are the problem. The reason is because of how the Edit in Datasheet view works with these columns. I don’t have the 100% accurate explanation of this, but it appears that SharePoint gets from its “user store” all possible users and puts them into a dropdown list. If you are in the Edit in Datasheet view and dropdown a Person or Group column, you will see what I mean. So, what is happening is you have users in your spreadsheet data that is not in the SharePoint “user store”. Hence, invalid data.
Step 4: Fixing the Invalid Data error
So, how do you fix this? Easy, return to Excel for a quick moment. Create a new column in your spreadsheet. Using the CONCATENATE function, append a semicolon onto the end of either the user Display Name or Account (keep in mind, this is the data I got from AD). Now that you have a list of users with a semicolon at the end, copy that column and return to SharePoint.
Go to the Site Settings of the site where your list is and go to People and Groups. Create a new group, naming it so that it sticks out like a sore thumb. Now, add users to this group. In the Users/Group textbox, do a paste. What should happen is everything you copied from the spreadsheet (users with an semicolon appended to the end) should have pasted. Uncheck the “Send email” option and click Ok. The group should be populated with all of the users. Great. Now, delete the group.
This is the magic operation to get Edit in Datasheet People or Group dropdown list populated with the values you need!
Step 5: Finally, Populating the List
Return to your list and change back into Edit in Datasheet mode. Now you should be able to copy and paste your Excel data directly into the Datasheet, without error. It is as simple as that!
Monday, November 24, 2008
Validation of viewstate MAC failed as a result of 3.5 SP1
On the eve of installing the 3.5 SP1 framework on our production IIS servers, I uncovered a problem on our development server. Today I went to use a rather old application 2.0 on DHSIISD1 for a totally unrelated note and found that it was getting a runtime error. The error that was being produced was as follows.
Validation of viewstate MAC failed. If this application is hosted by a Web Farm or cluster, ensure thatconfiguration specifies the same validationKey and validation algorithm. AutoGenerate cannot be used in a cluster.
After spending the past 4 hours trying to determine the root cause, I found that it has to do with the installation of the 3.5 SP1 Framework. How I determined it is what introduced the problem is because I could run the ASP.NET app without error locally on my PC (it also runs in production right now). I then installed the 3.5 SP1 Framework on my PC. After the installation the application running on my PC begin exhibiting the same symptoms. Then I began reviewing what changes were being addressed in the 3.5 SP1. There was a feature put in that allows you to set a form’s Action (HTMLForm.Action) during runtime for example. It is my belief that this is what broke the app. Actually, “broke” is rather subjective. There are a few things to make this stop working.
First, the page in question had controls that caused post backs to occur. The page also had a HTML form defined and the form has an action set.
Validation of viewstate MAC failed. If this application is hosted by a Web Farm or cluster, ensure that
After spending the past 4 hours trying to determine the root cause, I found that it has to do with the installation of the 3.5 SP1 Framework. How I determined it is what introduced the problem is because I could run the ASP.NET app without error locally on my PC (it also runs in production right now). I then installed the 3.5 SP1 Framework on my PC. After the installation the application running on my PC begin exhibiting the same symptoms. Then I began reviewing what changes were being addressed in the 3.5 SP1. There was a feature put in that allows you to set a form’s Action (HTMLForm.Action) during runtime for example. It is my belief that this is what broke the app. Actually, “broke” is rather subjective. There are a few things to make this stop working.
First, the page in question had controls that caused post backs to occur. The page also had a HTML form defined and the form has an action set.
Monday, October 6, 2008
Understanding Kerberos and Service Principal Names (SPN)
The best explanation and tool for troubleshooting problems with Kerberos and delegation in an IIS environment.
http://blogs.iis.net/brian-murphy-booth/archive/2007/03/09/the-biggest-mistake-serviceprincipalname-s.aspx
http://blogs.iis.net/brian-murphy-booth/archive/2007/03/09/the-biggest-mistake-serviceprincipalname-s.aspx
Tuesday, September 9, 2008
Nice Free Geocoding Web Site
I needed to be able to quickly geocode some addresses and this site did just that AND it was free.
http://www.batchgeocode.com/
http://www.batchgeocode.com/
Subscribe to:
Posts (Atom)