Archive for the ‘SQL Server 2008’ Category


The SBS implementation of SharePoint Foundation relies on SQL 2008 R2 Express and any database has a size limitation of 10GB. Because I am a SharePoint bigot, I encourage my clients to take advantage of SharePoint and use it instead of shared files.  It certainly offers lots of benefits:

  • Version control
  • File granularity for permissions
  • Remotely accessible without the need for a vpn connection
  • Check-out and check-in for editing protection
  • Discussion groups and custom lists
  • Blogs and wikis
  • And lots more

SharePoint is also easily managed once you get the hang of it.

(Anyway, I will do another post on how users are taking advantage of SharePoint to do things for their businesses.  But this post focuses on what to do when they have done things too well and grown up to the maximum database size.  It equally applies if you just want a new web application – perhaps because you want different permissions on it from the standard site.)

Mulltiple Databases

While the maximum size of a single database is 10GB, a SharePoint installation can have multiple databases.  You can create a new web application with a new database in a single step.  SharePoint does all the heavy lifting for you.

These steps are done in SharePoint 2010 Central Administration.  Lacnch it on your SBS Server and see the home screen:

Farm Management Home Page

Under Application Management, choose the first item, Manage Web Applications:

You should see your SharePoint site and Central Administration.  On the ribbon, click on New and the following page opens.  I have filled it out with information to create both a new web application and a database to support it.  The fields I added or changed are highlighted in yellow.

Fields I Changed

The first field I changed was the suggested value for creating a new IIS web site.  SharePoint proposes the name

SharePoint – <random port number>.  You can use any name you wish if it is unique among existing web site names (see IIS display if you don’t know).  I decided to pick port 988, one above the SharePoint 987 for //companyweb.  So I changed the port number to 988.

SharePoint also suggest a database name of WSS_Content, which I changed to NewDataBase.  You can, and probably should, use a name that is relevant to your site like AdminData, HistoryData, etc.

If you want to use the SBS server for searching, click on the drop down box and select it.  Then click ok; you can leave the other fields as is. Once the processing screen finishes – it can take a few minutes to create the web site, application pool and update SharePoint configuration – you get the following notification

Application Created

Now Create a New Site Collection

Click Ok, and then Central Administration to go back to the home page.

While you have created a new web application, it is not yet a site that you can browse to.  You first have to create a new site collection.

Now click on Create site collections to see the site collection page.  The first thing to do is to select the web application.  On the upper right of the page you would see Web Application: and probably http:<something>.  Hopefully the something ends in :988 or whatever port you chose.  If not, click on the drop down arrow, chose change web application and then select the one you just created.

New Site Collection

Enter a site collection name in Title and a description of you wish.  Pick the type of site you want to create by choosing a template.  Then enter names for the site administrator; click on the book icon to search or type it in directly and check the name withe the person + check mark icon.  Set a quota if you have them defined and want to.

Then click ok,  and as if by magic you have a new site for your new web app and database.

Repeat the process as you need to.  In another post to come, I will go over how to customize the sites to have them all accessible from the same broswer.

What Has Just Happened?

SharePoint was busy doing some behind the scenes work for you.  It created a new Applicaiton Pool and Web Site you can see in IIS:

ApplicationPool Created

New Web Site Created

SharePoint also created a new database for you:

New SQL Database

Don’t  Forget

If you want to have this site available outside the LAN, open the port on your router and point to the SBS server. The internet URL is http://remote.<domainname&gt;.com:988 or whichever port you chose.

You can also create  apublic URL and put it in your root DNS provide that you configure alternate access messages.  Again, in another post on how to customize your new site and link the original, if you wish to.  Although you might want to have entirely different permissions on the two sites for application reasons.


Now that you have the basics of how to create a volume on an iSCSI target and mount it for use, let’s explore some reasons for doing so.

Server Storage

The simplest case I will present is a single SBS server.  There are several important data stores for SBS:

  • Exchange Server
  • SharePoint
  • Shared folders
  • LOB or other data that is used by SBS members

When you first install SBS, these are all going to be located on the OS drive.  Using the SBS console, you can migrate them to another drive location.  In the case of LOB data, which is set up independently, you no doubt can chose the drive on which to locate it.

You could start with disks installed on the server in a traditional fashion.  Maybe the drives are 500GB, 1TB, or larger drives.  Your Exchange requirements might be modest, say 15GB.  You estimate that SharePoint files are likely to grow to 20GB in the next six months to a year.  Shared folders might start at 20GB but could go up or down depending on what migrates to SharePoint, for example, and what other growth you anticipate.

You can use one drive for Exchange, one for SharePoint, one for shared folders, and one for LOB data.  But perhaps your server can’t accommodate that many drives.  And it certainly might not accommodate them as RAID 5 or 6 volumes and be independent of each other.  What are the choices?  Well, you could  use one physical disk, no RAID, and create several volumes and use different ones for different data types.  Or perhaps use several drives to create a RAID set and and allocate volumes on it.

Now that you have several volumes on your drive or drive array, sized to accommodate the data you anticipate, what happens if you start to run out of space?  If you have a partition management software tool, you could expand the size of the allocation if there is more free space on the drive(s), or shrink another partition if that were possible and then increase the size of the desired one.  Or, if you have the space available, create another larger partition and move the data to the new one.

Using iSCSI targets is similar to this approach but without the drawbacks and pitfalls of locally attached drives.  First, your storage platform is robust and will have RAID enabled drive support.  Since mountable drives are created from an available pool of space, you can start with the most reasonable size for each disk you need.  Later, you can, on the fly, create a new iSCSI target that is larger or smaller, move or migrate the data to it, disconnect the original target and then delete it.  It is far easier than partition management.

Don’t forget backups.  You can create an iSCSI target and mount it on the SBS server and then configure backups to this drive.  Need another destination?  Very simple.  You get the idea.

Virtual Machines

You probably know from reading some of my other posts I am a fan of virtual machines.  I like the idea of running SBS as a Hyper-v machine; the same box can support test machines, client machines used for remote access, special LOB servers, you name it.  In a virtual machine environment, iSCSI shines.

Start with the drive on which you store the .vhd files.  These can be on a locally attached or a iSCSI drive.  I use iSCSI because I can allocate a right-sized disk in a matter of minutes and have it available on the host server.  Once the virtual machine is created, I can allocate and attach additional iSCSI targets to meet the needs of that vm.

Consider that you might want to test some new software or application, such as a web site, SharePoint feature, or LOB application.  Create a virtual machine and allocate the disk space it needs.  If it turns out to be incorrect, or once your testing has been completed, it is a simple matter to delete the iSCSI targets and return the disk space back to the available pool.

Note a potential disaster recovery scenario.  If you were to lose the host server, the .vhd for the virtual machines would still be on the iSCSI target.  Simply use them to create a virtual machine on another host, and you are back up and running.


Admittedly, I stole some of my own thunder when talking about virtual machines, but the testing environment is perfect for iSCSI.  Just allocate a target, use it and then delete it once the testing is done.

But it is not just for server and server-level software that iSCSI is useful in testing.  Suppose you want to test from your desktop.  Guess what.  Windows 7 has the same iSCSI initiator, and you can download one for XP.  That means you can create disks, use them and subsequently delete them at the client desktop as well as at the server.

Ad Hoc Uses

I have also used iSCSI targets for quick, one time efforts.  I wanted to update the OS on a laptop for a friend, and I wanted to end up with a clean install but make sure I didn’t lose anything important.  The trouble was that my friend couldn’t tell me what was important…. So I removed the laptop drive, connected it to my desktop with a USB drive connector, copied it completely to an iSCSI target I created, put the drive back in his laptop and installed the new OS.  There were a few things to go back and retrieve, but once he was satisfied I simply deleted the drive.

I will often be called upon to change something at an installation.  I usually create an iSCSI target, do an appropriate backup (sometimes it is just copying files, other times, a more holistic backup), then make the changes.  Getting back to the original state if something goes wrong is neat and tidy; so is the deletion of the disk once I am done.

Less Common But On My Wish List

Recall from Part I that the SCSI commands to read and write data are sent over the network to the target device.  Theoretically, it doesn’t matter whether the network is local or very WAN.  Practically, it is how long it takes for the commands and data to get back and forth.

Here is where I think cloud backups might go for some types of transaction-sensitive data.  Suppose you have a database that gets updates continuously from user transactions, web traffic, etc.  If that data were stored on an iSCSI target, remember that the data and commands to read and write it travel across the network.  Now imagine that the iSCSI target machine, when it gets a write command, also sends that command with the data to another iSCSI target, a mirror, that is remote, i.e., the cloud (public or private).  The difference is that the local target can respond back to the server that the write is complete, but there are no such time constraints on the write to the cloud. The iSCSI target would have to create a queue of writes and execute them in order as they complete asynchronously to the writes it completes locally.  This is not unlike playing a log file against a database.

Because only writes need be executed across the WAN, this is a very efficient operation and with broadband speeds continuing to increase, such a scheme because a very practical continuous backup procedure.

No solution like this is commercially available that I know of, and it would not be appropriate for every application.  Nevertheless, you heard it here first if it does come to pass.

I hope this gives you a flavor of the convenience and wide range of uses that iSCSI provides. In Part III I will discuss the costs and purchasing of a unit.