Boolean1

Small Business Server 2003 R2 and SQL Server Workgroup Edition

Whilst Windows Small Business Server 2003 R2 includes Exchange Server 2003, SQL Server 2005 Workgroup Edition, ISA Server 2004, IIS 6.0, WSUS 3.0, Domain Controller, DHCP Server, DNS Server, and all that -- some companies may choose to install business applications on a separate server on the same "Small Business Server 2003 Network."  These separate servers on the small business network are referred to as member servers, or Windows Server 2003 Member Servers.  We're presently quoting a system, and seeing that the member server could also be a Windows Server 2008 Member Server.  So, our client has an M1 MRP system that they're migrating over from a legacy SQL Server 2000 machine that is currently not part of the domain.  The SQL Server 2000 database is going to migrated to a new SQL Server 2005 machine on the Small Business Server domain. 

One of the questions that came up was licensing: if the SBS 2003 R2 software includes SQL Server 2003 Workgroup Edition, can that software be placed on a separate (member) server without purchasing additional client access licenses?  It turns out that the answer is "yes," if you are, in fact, talking about SQL Server 2005 Workgroup Edition, and not SQL Server 2005 Standard Edition.  Client Access Licenses (CALs) are also not required for the Windows Server 2003 R2 machine.  This turns out to be a tremendous value to the customer as this database server can now be used for Windows SharePoint Services 3.0 where it is anticipated that all the users in the whole company will be accessing the database, and no additional user licenses are going to be required.

Here's a couple of links to articles discussing these licensing issues:

Product Use Rights - see pg 31 & 32 which shows that SBS CALs work for Windows Server Standard and pg 42 shows that SBS CALs work for SQL Workgroup Ed.

More SBS 2003 R2 Licensing FAQ's

Bottom line: SBS CAL's turn out to be a great value!

Dynamics SL 6.5 to 7.0 Upgrade

Well, I have to admit, we're slightly behind on the current version of Dynamics SL for our biggest client.  They reason is that we wanted to test out this whole upgrade prior to performing it in the live environment.  We were able to upgrade the SyncraTec internal-use Dynamics SL system several months ago, and experienced no problems.  Re-activating all the modules was a little burdonsome, as adding the unlocking keys with the Transaction Import did not go as smoothly as expected.  But there weren't any other many problems with the upgrade.

And keep in mind this is a triple-upgrade:

• Dynamics SL 6.5 to Dynamics SL 7.0
• Windows SharePoint Services 3.0 to Windows SharePoint Services 4.0
• Business Portal for Dynamics SL 3.0 to Business Portal for Dynamics SL 7.0

And these are all business critical -- and the SharePoint site has been customized, and it is very large...so, again, we wanted to test it all out in the test envirnment prior to upgrading in live.

So, since our client didn't have a test environment, we were tasked with creating one.  We accomplished this using Vitual Hard Disk (VHD) images of each of the three servers invloved (domain controller, database server, web server), and added those images to a Microsoft Virtual Server 2005 R2 environment.  After a re-activating the copies of Windows Server 2003 R2 on each of the VHD's, and manually configurating a couple settings like NIC card IP addresses, we were good to go.  Getting the VHD images of the servers can be challenging -- we used Acronis True Image software to obtain the VHD's.

The first problem we experienced with the test upgrade had to do with the switchover from SQL authenticated user accounts to Windows integrated user accounts.  The database upgrade asks you which windows account you want to map to the Dynamics SL System Admin account.  The account we picked was a dedicated account that we use for system admin duties.  Unfortunately, when we logged on with that account after the upgrade, we were unable to see any of the applications.  And this is the account that must be used to grant all the other user accounts access!  So, that's why we're really happy we doing this in the test environment first.  It was actually quite a lot of work to figure out the whole test environment thing, but it will be of great use going forward for these kinds of situations.

We're told that one of the solutions to the sys admin account not seeing the applications is to apply Service Pack 1.  We'll get that done and report back on the rest of the upgrade, as we progress.

SharePoint RS

Reporting Services - SharePoint Integrated Mode is a great way to deploy your SQL Server Reporting Services reports.  Once the environment is configured, running the reports couldn't be much easier.  Basically, users can launch reports with a single-left-mouse-click from a Windows SharePoint Services 3.0 Document Library.  If parameters are included in the report, the user would then have to select the date range, for example, of the report, and then the report rendors in the report view.  From there, you can export to Excel or .pdf.

Setting up the whole thing can be tricky, though; especially if you've got separate servers for your Database and SharePoint site.  Hint: you'll need to put on your Kerberos / Set SPN hat.  (Easy when you know how.)  You can also make the SharePoint site Web-accessible if you add SSL certificates to both the database server and the SharePoint server.

One of our clients found that deploying and running reports using Dynamics SL 6.5 with Business Portal 3.0 was rather difficult.  Well, the running of the reports was problematic at least because the Dynamics SL Application Server (separate machine used exclusively to run user reports) kept hicupping and that basically stopped the report service.  Meanwhile, when users do run reports, they don't get any feedback for about one minute in a best case scenario.  Then, when the report doesn't show up after a minute they don't know whether to wait a little longer, or call I.T. to check to make sure the report server is still running.  Not a great scenario.

When deploying a reporting solution, or any I.T. solution, you will want it to be one that users will readily adopt.  And they will adopt it if it is easy to use and gives them the information they need.  All signs are positive that SharePoint RS will accomplish those two goals.

Oh yeah, you'll also love how easy it is to deploy reports from within the Business Intelligence Development Studio.  How about right-mouse-click -- deploy.  Nice.

Specify Hardware Configuration of SQL Server

One of the things we as I.T. consultants have to do on a regular basis is specify the hardware configuration of servers.  An important consideration in the process is to decide how many hard drives are necessary, with what level of redundancy, how big to make the partitions, and which programs, data, bits, and bytes should go on which drives.  I found a great article by Denny Cherry on this topic that really gives a nice overview of the main considerations for specification of the hard drive attributes of a SQL Server.  I was pleased to see that the recomendation for an SQL Server in a small business environement could be accomplished with as few as five physical drives: two in RAID1 configuration for Windows Operating System plus SQL Server program files; and three for data files, log files, and tempdb database in a RAID5 configuration.  Several important points are noted in the article including key definitions, a discussion of the trade-offs between recovery time and the risk of a second failure prior to achiving full recovery to redundant operation, and lastly an important recommendation to use DISKPART to manually format partitions to ensure the disks are aligned to 64 blocks...read on...Tips for optimizing disk configuration in SQL Server