Here are some resources that come in handy:
- Completing Setup: Microsoft Windows Small Business Server 2003 R2 (Word document download).
- Release Notes for Windows Small Business Server 2003 R2
- Install the base OS to the primary OS drive formatted leaving 10 GB unused on the drive during setup. All other drives/partitions should be left untouched at this time.
- Stop the continuing setup after the reboot by cancelling it.
- In between Phase 1 and Phase 2: Install relevant drivers, format the partitions and drives.
- Move the Swap File over to the partition created out of the above 10 GB. This partition can be used for the ISA URLCache as well.
- Verify all devices are recognized and happy.
- Run Phase 2 setup via the Setup icon on the desktop.
- We set the MSDE Engine, Users Shared Folders, Client Applications, and Sent Faxes to the same drive/partition.
- Finish the install by completing the ToDo tasks.
- Install the Premium Technologies with SQL Server 2005 Workgroup Edition followed by ISA 2004 SP1.
- Note that during the ISA CEICW one will need to recheck any extra settings at the Web Services Configuration step.
- Make sure that the Create Certificate is also left at the setting it chooses.
- Install the components and updates from the R2 Technologies CD.
- Complete the Post Exchange SP2 Must Dos (previous blog post).
- Update the Exchange registry settings for the Greylist problem that Exchange seems to be having: Exchange may not be retrying! (previous blog post)
- Install WSS 3.x in side-by-side mode (official SBS blog post on the matter). Why? Because the WSS 3.x and Outlook two way functionality may be required for WSS hosted calendars, or the Recycle Bin may be for those who "accidentally" delete files.
- Install WSUS 3.x afterwards (previous blog post on WSUS 3.x install experience).
- At the command prompt, run the appropriate osql commands to tame SQL's memory usage (previous blog post explanation).
- RipCurl the SBS R2 box for Vista and Office 2007 compatibility (previous blog post).
If newer Service Packs exist, do a bit of searching to verify their compatibility with your SBS installation before installing them. A good example of this is Windows Server 2003 Service Pack 2 as there are lots of caveats on SBS (KB 555912) .
Our partitioning schemes (previous blog post) come via experience trying to recover multiple partitions on one drive or array. That can be extremely difficult. Sometimes, KISS really works. :D
UPDATE 2007-09-06: Reversed steps 13 and 15 to set them in the correct order!
UPDATE 2007-09-07: Added the Exchange registry settings for its seeming difficulty with Greylisting and Tarpitting and the RipCurl step.
Philip Elder
MPECS Inc.
Microsoft Small Business Specialists
4 comments:
Excellent post, Philip.
One question I have for you:
Why don't you place the Exchange Database in the same drive that he User Files are located? I only ask because every book I've ever read seems to suggest doing so.
-Alex "Achito" Tunon
AMDG
Alex,
That is a tough one to answer since it comes via many years of experience recovering sometimes insanely toasted drives and arrays.
Sometimes, the KISS principle - Keep It Simple Stupid - goes a long way towards getting things back on track.
I have read some of the justifications for moving the Exchange dbs to separate partitions ... however, in a worst case scenario where the SBS box has gone completely sideways and the backups are toast - you do verify your backups right? - you can still fall back on the Outlook client export or OST to at least get e-mail/contact/calendars both private and public folders back.
There is no replacement for off-site proven backups. Period.
Client production can resume with two essential elements in place: Data & E-mail. Server recovery proceeds from there ... whether by Swing if you have a second DC, by backup recovery which has its own caveats depending on the age of the backups, and now possibly via StorageCraft's ShadowProtect products. The last one is in the process of being tested and is looking very promising.
What are your thoughts on the matter?
Philip
Philip,
Essentially as a performance best practice. One can argue that in a small environment, the gains would be irrelavent, but even if that were so, is there any reason to NOT put the database file where the SQL database and User Files are? What makes it any more "KISS" by keeping it on the OS partition.
BTW, I am not arguing against putting it on the OS partition, I really want to know and learn. :-)
-Alex
AMDG
Good point ... memory has a way of fading a bit ;0) And in this heat, my default brain move was recovery over performance. My bad. :)
Performance on a physical device can only go so far.
In the days of SCSI and now SAS, having multiple partitions on one drive or array would make some sense. SCSI/SAS can process multiple requests with SAS totally kicking SCSI's butt in performance today.
However, on the SATA platform where NCQ which is supposed to work like SCSI command queuing, but doesn't really do the job, having more than 2 partitions on one drive/array set is bad practice. The drives can only do so much before performance is compromised, and heads dancing across the platters to three different locations in the case of 3 partitions doesn't really work well.
So, on the bigger SBS servers we do the following:
RAID 1: C: (System), S: (Swap).
RAID 1: G: (VSS images), server storage. Exchange dbs here too.
RAID 5: H: Client Data, Company shared folder (WSS does not work for 300GB+), Users folders, Client
Apps, etc.
In the era of cheap SATA storage (1TB drives in the pipe now at less than $500), there is no reason why one would not utilize those 6-10 Hot Swap bays. The above configuration would be 10 drives with a Global Hot Spare.
The example used in the blog post is a small client SBS box, 2 x RAID 1 arrays. The second array is used for client data. VSS images are shifted to the C:. Exchange dbs stay in the default location on the system partition. More memory is better for Exchange's hungry memory caching.
In a production SBS box of at least 10 users do the following if you have not already done so:
Open Task Manager
Click View
Select Columns
Click the following (I forget which ones are there by default so excuse any duplication):
PID
CPU Usage
CPU Time
Memory Usage
Memory Usage Delta
Peak Memory Usage
I/O Read bytes
User Name
Virtual Memory Size
I/O Write Bytes
I/O Other bytes
Click OK
Now have a look at the data. After looking at these lists over the years, one can determine which processes are the most hungry for memory, Store, and which are more I/O intensive.
You can click on the columns to sort by the respective data set to further get an idea of what is happening on the server at any given time.
Sysinternals also has some pretty good utilities to check into what is what in the server processes.
That help to further develop my somewhat heat-stroked thinking processes! :D
Philip
Post a Comment