Monday, 9 July 2007

SBS 2K3 R2 - Setup steps and resources.

We are running through some setup scenarios on SBS 2K3 Premium R2.

Here are some resources that come in handy:

In our experience, to augment the Completing Setup document we do the following when installing SBS 2K3 R2 Premium:

  1. 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.
  2. Stop the continuing setup after the reboot by cancelling it.
  3. In between Phase 1 and Phase 2: Install relevant drivers, format the partitions and drives.
  4. 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.
  5. Verify all devices are recognized and happy.
  6. Run Phase 2 setup via the Setup icon on the desktop.
  7. We set the MSDE Engine, Users Shared Folders, Client Applications, and Sent Faxes to the same drive/partition.

  8. Finish the install by completing the ToDo tasks.
  9. Install the Premium Technologies with SQL Server 2005 Workgroup Edition followed by ISA 2004 SP1.
  10. Note that during the ISA CEICW one will need to recheck any extra settings at the Web Services Configuration step.
  11. Make sure that the Create Certificate is also left at the setting it chooses.
  12. Install the components and updates from the R2 Technologies CD.
  13. Complete the Post Exchange SP2 Must Dos (previous blog post).
  14. Update the Exchange registry settings for the Greylist problem that Exchange seems to be having: Exchange may not be retrying! (previous blog post)
  15. 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.
  16. Install WSUS 3.x afterwards (previous blog post on WSUS 3.x install experience).
  17. At the command prompt, run the appropriate osql commands to tame SQL's memory usage (previous blog post explanation).
  18. RipCurl the SBS R2 box for Vista and Office 2007 compatibility (previous blog post).
In the case of the R2 Tech CD, verify that the Service Packs are still current before installing.

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
at

4 comments:

  1. Anonymous13 July, 2007 10:48

    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

    ReplyDelete
  2. Philip Elder Cluster MVP13 July, 2007 12:30

    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

    ReplyDelete
  3. Anonymous13 July, 2007 13:00

    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

    ReplyDelete
  4. Philip Elder Cluster MVP13 July, 2007 13:57

    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

    ReplyDelete

NOTE: All comments are moderated.