Eric Cherng

In the first part of this article, I discussed how to use the simple Blocked file types feature to provide some basic security protection. Although this feature makes it very simple to provide some security, in the long run it does not provide a complete solution to protecting your servers. In this post, I will focus on SharePoint's second line of defense: built in Antivirus support.

Setup

If you look in Operations, Security Configuration, you can find the Antivirus feature.

 

If you check the Scan options here without actually installing an antivirus program, SharePoint will do nothing. This is a very bad design. Instead of gladly accepting the changes, SharePoint should let the user know that no antivirus application is installed and that these options will not do anything. An unsuspecting SharePoint admin who does not know this behavior will get a false sense of security, leading to big problems down the road.

So what SharePoint actually provides is not built in antivirus scanning, but the support to plugin your own antivirus software. Luckily for us, Microsoft recently released a beta version of the Forefront product line for SharePoint called Forefront Security for SharePoint. You might recognize the Forefront name associated with Exchange server. Now there's a version for SharePoint. This software will not only allow us to scan for viruses using multiple scanning systems, but also scan for malware!

So to actually enable antivirus scanning on your SharePoint server, the first thing you will need to do is install Forefront for SharePoint (or any other antivirus program that supports SharePoint). As you can see, Forefront's setup is really simple:

 

Once you install Forefront, the next thing you want to do is make sure it is configured properly. Use the Forefront Server Security Administrator console to configure Forefront:

 

As you can see, Forefront provides many options so it may seem daunting at first. Still it is a good idea that you review all the options to make sure you didn't miss anything.

And finally, don't forget the last step: once you've installed your antivirus scanning program, in this case Forefront, make sure to enable the scan options in SharePoint to enable scanning.

That's all you'll need to do to setup your server for antivirus protection! Can't get any simpler than this!

 

Scanning

Now let's say you want to manually scan your SharePoint installation. In the Security Administrator console, just go to the Operate section and click on the Quick Scan option. Select the sites you want to scan and hit the Start button.

 

So on Monday, Bob from Sales gets a "contract" document from a potential customer. Being the awesome team player, Bob immediately uploads the file to SharePoint to get feedback from his other team members. Uh-oh... looks like there's something wrong with the file. SharePoint shows this page when a virus is detected with an uploaded file:

 

Note that I did not really upload a virus onto our SharePoint server. My virus is just a "test" virus.

While the benefits of installing an antivirus solution into SharePoint is clear, what tradeoffs exist with having antivirus enabled? After installing Forefront, I noticed the following behavior with SharePoint:

• Forefront takes a significant chunk of memory on the server.
• Downloading files will takes longer.

Hopefully some of these issues is because Forefront is still in beta. Whether these tradeoffs are acceptable or not depends on your organization and your security needs. Personally I feel the need for security and protection against a virus aftermath far outweighs these tradeoffs.

So that's a quick walkthrough of antivirus support with SharePoint, more specifically the Microsoft Forefront product. As you can see, adding antivirus support into SharePoint is fairly simple, and takes security on your server to a whole new level. Combining Blocked file types along with antivirus support provides a comprehensive security protection plan for your SharePoint server to protect against those miscreants out there.

 

Everyone can agree that SharePoint is a great platform to facilitate collaboration amongst team members. One of the main benefits of collaborating using SharePoint is working on documents together with your team. The workflow for collaborating on documents is something like this:

1. Create the document and edit initial draft.
2. Upload to SharePoint document library.
3. Send email to colleagues on document location.
4. Reviewers provide feedback and update the document as needed.

All this is great, but in the world that we live in, security is an important issue to consider, even amongst your team mates. Of course we all trust the people we work with, but sometimes there are just bad apples out there.

In the steps mentioned above, step 2 is where trouble can come in. Once a bad file is uploaded onto SharePoint, unknowing colleagues that download the document will catch the cold and spread the disease. This becomes an even bigger problem if SharePoint is configured for extranet access where people outside of the network without the same security restrictions can upload files.

So ignoring my dramatic example, what facilities does SharePoint provide to help prevent such security breaches? The good news is that SharePoint has 2 built in features that will help with this:

• Blocked file types
• Antivirus

These are 2 broad features, that I will split the discussion of into 2 posts: this post will discuss the Blocked file types while my next post will describe the Antivirus support.

Both of these are configured through the Operations tab in Central Administration.

 

If you click the Blocked file types link, this will bring you to the configuration page where you can edit the list of file types not allowed on your SharePoint server.

 

So what does Blocked file types do? Blocked file types is a simple method of allowing only certain file types to be uploaded onto SharePoint. While this doesn't completely prevent files with viruses from being uploaded, it makes it less likely that a user will unknowingly click on such files and infect his own machine. For example, EXE files are by default a part of the blocked file list and cannot be uploaded directly. SharePoint responds to EXE uploads with the following message:

 

If an EXE file named "2006 Budget.exe" was uploaded onto SharePoint, the company financial officer may not notice the EXE and accidentally click on the file, thus executing the rogue application causing havok on his machine.

However, a malicious user could simple rename the file "2006 Budget.exe.xls", which would bypass SharePoint's file extension check and allow the file to be uploaded. Although the file uploaded is actually an EXE, the file extension is what determines how a file is executed. So instead of running the EXE directly, Excel will attempt to open the file and thankfully fail since it is not a recognized format.

 

Still, having an EXE on your server is not something IT will like. Who knows, the next day, someone may find an exploit within SharePoint that lets any process to run. When that day comes, you don't want to be around!

So as you can see, Blocked file types allows for a simple way to mitigate some the risk of uploading rogue files. As I mentioned, even though the risk is somewhat less, rogue files can still be uploaded onto the server. If some other server-side security hole is found, the rogue file on the server can potentially cause problems on the server, leading to even more security problems and potentially loss of data. That is how the other security feature of SharePoint comes into play which I will elaborate more on in the second part of this post.

 

A question came up last week in what permissions does the account that SharePoint uses to connect to SQL need. Unfortunatey I couldn't find the answer to this after doing some internet searches so I just decided to give it a try and see.

After installing MOSS 2007, setup will bring up the SharePoint Products and Technologies Configuration Wizard. Essentially this wizard creates the Central Administration site so you can setup the rest of your MOSS installation.

Obviously the first security check is to make sure your user account running setup has permissions on the database server to create new databases. The wizard to create the Central Administration site will be running in your user account context to create the database so you have to at least have permissions to create a new database. Your user account should also have permissions to create a new IIS site, but since this post is about the database, I'll leave that topic for a future post.

Second user account you have to consider is the user account you specified in the wizard that SharePoint uses to connect to the database. SharePoint will be using this account not only to read and write to existing databases, it will also use this account to create new databases when you create a new SharePoint web application. Therefore a simple datareader or datawriter role is not enough.

Turns out the wizard will take care of adding the user you specified into SQL Server and then assigning the necessary server role. In my test install, it looks like SharePoint requires the dbcreator and the securityadmin server role for the user account.

Down to the security for the specific database, the user account is granted db_owner permissions.

Another note on picking the user account for SharePoint to use to access the database, if you are doing a multi-server installation of SharePoint, make sure to use a domain account. You could also create a shadow account, but that is not a recommended way of installation.

Does your SharePoint My Site show your domain username instead of your full name? We noticed this behavior during our test installation of Microsoft Office SharePoint Server 2007 Beta 2 Technical Refresh. After tesing out different theories of why this was happening, we realized that the reason for this is because the identity of the application pool for the SharePoint site was using a local machine account instead of a domain account. Since the account was a local machine account, it doesn't have permissions to look up your user account information in the domain Active Directory... makes sense.

So the solution to this problem is to change the identity of the application pool. In order to do this, you will need to go to your SharePoint Central Administration page. Click the Service accounts option under the Security Configuration section.

 

In the Service Accounts page, change the Credential Management radio button to Web application pool. In the drop down, select Windows SharePoint Services Web Application. In the Application pool drop down, select the application pool you want to change the identity of.

 

Now the bottom controls should be enabled to allow you to change the identity of the application pool.

 

Once you're done entering in the user account and click OK, SharePoint will alert you to run IISRESET in order for the changes to take effect.

 

Once you run IISRESET /noforce, your app pool should now be running under the new identity. If you are in doubt, check Task Manager on the server and you should see the w3wp.exe process running with the new identity.

 

Also a warning, don't change the application pool user account through IIS Manager. If you do so, SharePoint's configuration will not be in sync with the app pool's identity and may also cause your web site to fail to load. I got this warning message in Event Viewer:

The identity of application pool 'SharePoint - 80' is invalid, so the World Wide Web Publishing Service can not create a worker process to serve the application pool. Therefore, the application pool has been disabled.

followed by this error message:

A failure was encountered while launching the process serving application pool 'SharePoint - 80'. The application pool has been disabled.

I've always found it difficult to remember where all the folders SharePoint uses are and what each folder is used for. So here's my attempt to consolidate this information in one post for easy reference. This post assumes default folder locations. Obviously if you customized anything, then you're on your own.

 

WSS/SharePoint Server Program Folder

C:\Program Files\Common Files\Microsoft Shared\web server extensions\12

C:\Program Files\Microsoft Office Servers\12.0 (not sure about this)

This is where most of the program files for SharePoint live.

 

WSS/SharePoint Binaries

C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN

This contains the executable binaries used with SharePoint. For example, stsadm.exe and the WSS Timer service, owstimer.exe, is located here.

 

WSS/SharePoint Server Assemblies, ASPX, ASMX

C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\ISAPI

Contains most of the ASPX (ASP.NET Web Forms) and ASMX (ASP.NET Web Services) files of SharePoint. Also if you are writing code that uses the SharePoint assemblies (ie. Microsoft.SharePoint.dll, Microsoft.SharePoint.Server.dll, ...), then the assemblies you need are located in this folder.

 

SharePoint Logs

C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\LOGS

SharePoint told you to check the logs? This is where you can find the raw log files.

 

SharePoint Site Features

C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\FEATURES

Looks like this is where all the SharePoint Features metadata is stored.

 

Site Layout Template

C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\LAYOUTS

This is the folder where the virtualized _layouts path for each site URL is located. Add additional files in here to have it be available to all sites.

 

SharePoint Setup Cache

C:\Program Files\Common Files\Microsoft Shared\SERVER12\Server Setup Controller

Looks like this is where SharePoint Setup stores the setup configuration. If you have Office installed as well, then this folder is also used for them.

 

Web Application Virtual Directories

C:\Inetpub\wwwroot\wss\VirtualDirectories

The folder where your SharePoint web applications point to.

 

Web Application web.config

C:\Inetpub\wwwroot\wss\VirtualDirectories\[web application]\web.config

Need to customize the web.config for a particular web application? This is the web.config that you want to edit. Replace [web application] to your web application first of course.

 

Install Web Parts per Web Application in here

C:\Inetpub\wwwroot\wss\VirtualDirectories\[web application]\_app_bin

Additional assemblies (ie. custom web parts) are installed here on a per web application basis. You can also install Web Parts to the GAC as well to be accessible in all web applications on the server.

 

This post compliments my post on SharePoint 2007's registry locations.

If anyone knows of any other interesting folder locations, let me know so I can add them here.

Wondering where SharePoint 2007 lives in the registry? Probably not, but here you go anyways.

Windows SharePoint Services (WSS) 3.0 is:

HKLM\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\12.0\

Microsoft Office SharePoint Server (MOSS) 2007 is:

HKLM\SOFTWARE\Microsoft\Office Server\12.0\

The usual warnings of the registry apply. You edit the registry at your own risk. I will not be held responsible for any actions you take with your registry settings!

Warnings aside, it's pretty interesting to see what goes on under the covers!

I recently had to move a site collection from one MOSS 2007 Beta 2 server to a VPC for archiving purposes. Even though SharePoint now has an easy way to backup/restore through Central Admin, I found the easiest way to get everything working with control over the process was through the command line admin tool provided by SharePoint: stsadm.exe.

Before running these commands, make sure the SharePoint bin directory is in your path. The SharePoint bin directory is by default located in C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN.

To back up a site collection, run this command:

stsadm -o backup -url <url> -filename <filename>

where <url> is the url of your site collection and <filename> is the file you want to backup to.

To restore the site collection, run this command:

stsadm -o restore -url <url> -filename <filename> -overwrite

where <url> is the url you want to restore the backup into and <filename> is the backup file.

The -overwrite flag is used to overwrite the existing site if it already exists. However be careful that you don't overwrite an existing working site. You can always run the restore first without the -overwrite flag to determine if you need the overwrite flag. The command will let you know if an existing site is already located at the url you specified. During my testing, I restored a site in the wrong place with the overwrite flag completely killing the original site. Thankfully I backed up everything before I made any changes.

One thing to watch out for when you restore onto a different server is the security. During my first attempt, my user account was not admin of the site collection. Backup went without any problems, but restoring would fail midstream. Turns out the restore process restored the original security permissions to the site. Once authorization kicked in, my account failed the security check causing the entire restore process to fail with a half restored site. If this happens to you, edit the existing site so that you have the needed permissions to perform the backup/restore, then backup/restore again.

Another tip when using the stsadm command is to make sure you review exactly what data is being backed up. Remember the command backs up only the site collection, so anything outside of the site collection scope is not included. Typical data outside of the site collection that still may effect your site include:

• Application settings in Central Admin
• Shared Services settings (search scopes, audiences, excel services, ...)
• Sub site collections

The last bullet is important to watch out for as I later found out that my original backup didn't include any sub site collections. Turns out personal sites (My Site for each user account) are sub site collections of the main site collection. If you just backup the main site collection for personal sites, this does not include any data of the sub site collections. You will have to backup those individually.

One of the more useful features in the next SharePoint is the ability to take data with you offline. So many times in the past I had to meet with a client in their office so the day before I would download all my documents stored in SharePoint one by one. What a pain! Now with MOSS 2007, I can do it all in one click!

Extranet access is one possible way to avoid the need to download local copies, but you still have the problem of needing an internet connection. Being at the client site, sometimes IT security makes it a big pain to get internet access (ie. have to get permission, need to authorize the machine, dynamic or static ip, WEP/WPA key, ...). There are so many other things you have to worry about, why deal with another issue?

So how do you do it? Very easy! Just go to the document library you want to access offline, click the Actions menu and click Connect to Outlook:

Outlook then will ask you whether you want to connect to the list or not. The first time I tried this I wasn't prompted with the dialog, while the second time I saw this screen:

Once you confirm OK, Outlook will create a new SharePoint Lists folder and download the documents to that folder.

What happens when you update your document library with new documents? Outlook will detect the new documents once you refresh the folder, but will not automatically download them.

You can selectively download individual files you want or hit the Send/Receive button to download all the documents. Unfortunately Send/Receive button did not work reliably for me: sometimes it would work, other times nothing would happen. Hopefully this is just a Beta 2 bug.

So what can be linked for offline Outlook access? A quick review of all the lists and documents on my personal site, I found these linkable to Outlook:

• Calendars
• Contacts
• Data Connection Libraries
• Discussions
• Document Libraries
• Form Libraries
• Picture Libraries
• Project Tasks
• Tasks
• Wiki Pages

These items can also be linked for offline access, but they go through Access instead of Outlook:

• Announcements
• Issue Tracking
• Links
• Lists
• Surveys

That's quite a list of data you can suck on your laptop before a client meeting!

 

There are plenty of guides out there detailing how to create a new Windows SharePoint Services v3 web part, so I won't write another one here. Those walkthroughs are great, but sometimes I just want a quick outline of the steps needed to get things done. So while creating my own web part, I kept track of the steps and created my own simple outline. Here it for your use:

1. Create the Web Part
   1. Create the DLL project in VS2005.
   2. Add Reference to System.Web.dll.
   3. Create a new Class file, inherit from System.Web.UI.WebControl.WebParts.
   4. Override the Render method and use writer to output the content of the web part.
   5. Strong name the assembly if installing to GAC.
   6. Compile.
2. Deploy Web Part (updated 11/2/06 with B2TR)
   1. For strong named assemblies, follow these steps:
      1. Copy your assemblies to the C:\Inetpub\wwwroot\wss\VirtualDirectories\[site directory guid]\bin folder or install to the GAC. Note assemblies in the \bin folder have less priviledges than those in the GAC. Test your web part to make sure there aren't any security problems.
      2. Modify the site's web.config and add a <SafeControl> entry. Should look something like:
         <SafeControl Assembly="[Web_Part_Assembly_Name], Version=[Version_Number], Culture=neutral, PublicKeyToken=[Public_Key]" Namespace="[Namespace]" TypeName="[Class_Name]" Safe="True" />
   2. For non-strong named assemblies, follow these steps: 
      1. Copy your assemblies to C:\Inetpub\wwwroot\wss\VirtualDirectories\[site directory guid]\bin folder.
      2. Modify the site's web.config and add a <SafeControl> entry. Should look something like:
         <SafeControl Assembly="[Web_Part_Assembly_Name]" Namespace="[Namespace]" TypeName="[Class_Name]" Safe="True" />
3. Configure the Web Part in SharePoint
   1. Go to Site Settings, Galleries, Web Parts, click New.
   2. Select your web part and click Populate Gallery button. Make sure the web part now shows up in the web parts gallery. If the web part doesn't show up in the list of New Web Parts, may need to iisreset.
4. Edit a page and add your web part in from the Gallery.

Note that these steps are for WSS v3 Beta 2. These steps may change at RTM. I'll try to keep this up to date if things change.

For more detailed walkthroughs of how to create ASP.NET 2.0 style web parts for WSS v3, here are some resources/links:

• Create a Sharepoint 2007 webpart step by step
• Write Custom WebParts for SharePoint 2007
• Walkthrough: Creating a Basic Web Part

Lately, I've been playing around quite a bit with the next version of SharePoint coming out with Office 2007 so I thought I'd share some thoughts/comments on my experience.

First of all, note the name change yet again:

• Version 1: SharePoint Team Services
• Version 2: Windows Sharepoint Services (WSS) Version 2 and SharePoint Portal Server (SPS) 2003
• Version 3: Windows Sharepoint Services (WSS) Version 3 and Microsoft Office Sharepoint Server (MOSS) 2007

While I understand the reasoning behind the name change, cmon guys.. stick with a name already!

There has been a ton of architectural changes between 2003 and 2007. Here are some highlights:

• Now built on top of ASP.NET 2.0 and leveraging many of the new features such as Web Parts and Master Pages.
• Sharepoint truly acts as an ASP.NET web application, no more ISAPI handlers. Instead Sharepoint uses ASP.NET HttpHandlers.
• Flexible authentication! Building on top of the provider model of ASP.NET 2.0, Sharepoint now supports pluggable authentication providers!

Some more exciting changes from the admin perspective:

• Everything is now a site. No more weird distinction between sites and portals.
• Built in recycle bin. Now the user can undelete their own files without having to call you up to restore from backup!
• 3-tier administrative interface. At first this was confusing to me, but after reading about it some more... now it makes sense.

 And finally some changes from the user's perspective:

• Much better My Site with support for blogs!
• Nearly everything supports RSS feeds.
• Any list can be opened up in Outlook, which creates a locally cached copy of the list.
• Tabbed interface, drop down menus, Ajax data retrieval.

I really can't emphasize how many new features they've packed into the new Sharepoint. My list of features here are just some of the more interesting changes I've learned these past few days. I can easily see tons of books written for this release filling up an entire bookshelf at the bookstore.

I love most of the changes Microsoft made to Sharepoint, but unfortunately tons of new features come at a price: confusing UI. Version 2 was really confusing. In version 3, things are a bit easier with some of the UI improvements, but I still find myself hunting down the location for a setting or trying to remember where I configured an option. I hope the road to RTM includes some more time to review the user experience and to improve on some of the more confusing aspects (just looking at the Admin screen and all those links gives me a headache!). Otherwise, I am really excited about the new SharepPoint and can't wait to see it released!