Authentication in SharePoint

One of the great things about an intranet site is allowing everyone in the company to access the data they need in one place. It is even better yet if they can remember one password to get to that information. If you are using NTLM authentication you can get this type of integration because users log into SharePoint with the same Active Directory accounts that they are logging into their systems and very likely, their email as well. This works even better if you set up a Global Policy to add the SharePoint site to the trusted Intranet locations in IE. The credientials of the users machine logon will automatically be passed onto SharePoint. (If you don't create a global policy, each user will need to add the SharePoint site to their Intranet sites individually and if you are trying to get people on board with SharePoint, you won't want them to have to do that.)

One of the interesting things that I have yet to find a solution for, is that when a user needs to log in (in the case that you want added security, see future blog post for more details on this), the domain does not automatically populate. If you try to just type in the login name and password, SharePoint will keep prompting and then after the 3rd time you will get Access Deined. This can become a sticking point for SharePoint because most users may not even know the domain that they are logging into. It would be nice if there was some way to prepopulate the domain part of the login and allow the users to only enter their username and password and the domain would be appended to the login automatically. I have yet to find a way to do this and am in the process of doing some more research on the topic. If anyone has any ideas on the topic, let me know.

Forcing a PDF to download in browser and Adobe error

A while back I had a request to offer two options to access a PDF file from a SharePoint site. One was to allow the PDF to open in the browser like normal and the second was to force the download prompt to the user. The second one was a little more tricky and I finally found a way to send the file in the Reponse in code and send it as an attachment and thus prompt the user to download the file. The code for that looks like this:

'Create an array that contains the contents of the file.

Dim mystream As Byte() = file.OpenBinary

'Clear the Response headers and set the response to be an attachment

Response.ClearHeaders()

Response.ContentType = "APPLICATION/PDF"

Response.Clear()

Response.AddHeader("Content-Disposition", "attachment; filename=" & file.Name) Response.BinaryWrite(mystream)

This seemed to do the trick until the other day when I had a client call and say that when they used the download mechanism to open the file and save it to their desktop they were getting an error in Adobe Reader 7. I tested it out and found the same issue when I downloaded the file. The error said that the file was corrupted and that reader could not repair it. I could open the file just fine using Adobe Reader 8.

The solution to this issue turns out to be that I missed a line of code in the above block that must leave the PDF file unwritten and Adobe Reader 8 can repair the file but 7 can't. I found a post by Rahul that described 4 different ways to download a PDF file. In one of the ways was the way I had used to force the download. I noticed a line that said Response. End().

I added this line to my code and suddenly the PDF files were no longer corrupt and could be opened in Adobe 7 as well as 8.

The final code ended up looking like this:

'Create an array that contains the contents of the file.

Dim mystream As Byte() = file.OpenBinary

'Clear the Response headers and set the response to be an attachment

Response.ClearHeaders()

Response.ContentType = "APPLICATION/PDF"

Response.Clear()

Response.AddHeader("Content-Disposition", "attachment; filename=" & file.Name) Response.BinaryWrite(mystream)

Response.End()

The nice thing about the above code is that the file.OpenBinary method is an SPFile method that opens a file from SharePoint as a byte array. It works really well for items like this.

When STSADM Export runs out of space

A little while back I had a client that called about a script we had created to automate SharePoint site backups. The script was written in PowerShell and basically went through the entire site and exported each site to a directory and then moved onto each subsite of that site. Once all of the sites were exported, it zipped all the files up and created one ZIP file.

The client was calling because the backups seemed to be sporadic in size. One dat the backup file would be 14GB and then the next it would be 35GB and then it would be 8GB. I knew that the script was not doing anything special so I looked into the client's server and found that there was only about 100MB of free space on their hard drive. It then made sense to me that the size of the files was so sporadic. What was happening is that there would be enough space on the drive to complete the first day's backup. Since the script was keeping 7 days of files, when it got to the next day it could complete that backup. But by the 6th or 7th day there was not enough space on the drive so it would back up what it could until it ran out of space and then fail. The next day the script would run and delete one of the large backup files and there would once again be enough space to backup completely. This would continue on.

I told the client that they would need more disk space as they were running out and that is why the files were different sizes. I just heard back from the client the other day and they said that the files were now the same size.

The reason I knew that the script was bombing out and just finishing was that I tried manually doing an export of a fairly large site and the export failed when disk space ran out but still created a file that just didn't include the entire site. Once you know that you would see why there were no errors anyplace to indicate a problem.