Announcement

Collapse
No announcement yet.

Terminal Server Drive suggestions

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Terminal Server Drive suggestions

    We have an SBS 2003 R2 and 2 Win 2003 R2 member servers. 1 member server has a role assigned as a Terminal Server and the other member server has SQL 2005 installed. Looking for best practice info in assigning the most correct drive letters for the Terminal Server and the SQL server.

    Greatful for any suggestions

  • #2
    Re: Terminal Server Drive suggestions

    I'm not quite sure what you are wanting to do:

    Assign drive letters to the local drives -- if so, C, D etc, preferably in order
    Assign drive letters to mapped network drives -- if so, do not use existing drive letters and choose the most appropriate e.g. Public = P Drive

    Please explain the problem a bit more

    Tom
    Tom Jones
    MCT, MCSE (2000:Security & 2003), MCSA:Security & Messaging, MCDBA, MCDST, MCITP(EA, EMA, SA, EDA, ES, CS), MCTS, MCP, Sec+
    PhD, MSc, FIAP, MIITT
    IT Trainer / Consultant
    Ossian Ltd
    Scotland

    ** Remember to give credit where credit is due and leave reputation points where appropriate **

    Comment


    • #3
      Re: Terminal Server Drive suggestions

      Thanks Tom,

      Here is my question. The TS has 2 drives in a R1 array. The SQL server has 2 arrays 1) R1 and the other R5. I just want to be sure that when the users log in to the TS that they are able to pass thru to the SQL server. Hope that this helps.

      Sorry for the confusion.

      Comment


      • #4
        Re: Terminal Server Drive suggestions

        Please expand on "pass thru".
        Cheers,

        Rick

        ** Remember to give credit where credit is due and leave reputation points sigpic where appropriate **

        2006-2099 R Valstar. This post is offered "as is" for discussion purposes only with no express or implied warranty of any kind including, but not limited to, correctness or fitness for use. Nothing herein shall be construed as advice. Attempting any activity based on information in this post is done at your own risk.

        Comment


        • #5
          Re: Terminal Server Drive suggestions

          OK sure. User logs in thru SBS server and then is able to log in to the TS via ??RDP which will pass them on to the application being run on SQL server. Don't really know how else to explain it.

          grazie molto!

          Comment


          • #6
            Re: Terminal Server Drive suggestions

            Still not sure what this has got to do with Drive configuration

            To use RDP, go to System Properties on the computer you want to connect TO
            Go to Remote Tab
            Turn on "Allow Remote Connections To This Computer"
            Add users allowed to connect remotely


            Tom
            Tom Jones
            MCT, MCSE (2000:Security & 2003), MCSA:Security & Messaging, MCDBA, MCDST, MCITP(EA, EMA, SA, EDA, ES, CS), MCTS, MCP, Sec+
            PhD, MSc, FIAP, MIITT
            IT Trainer / Consultant
            Ossian Ltd
            Scotland

            ** Remember to give credit where credit is due and leave reputation points where appropriate **

            Comment


            • #7
              Re: Terminal Server Drive suggestions

              Originally posted by f5mann View Post
              grazie molto!
              Va bene, va bene.

              Prego:

              I agree w/ Tommaso (Bare with me Tom. Anyone that gives me a "Grazie molto!" deserves a bit of Italiano) in that I do not believe the drive letter configuration on your SQL Server box will have any affect on your users.

              If I understand you correctly, the users will access the SQL Server database using the appropriate middleware and not physically log on to the SQL Server box.

              So drive layout on that box should be to make management of the database as easy as possible.

              Now for the world according to Rick on drive lettering. It is my "world" so if it does not work for you then have your own "world".

              A: is the floppy.

              B: is the "other" logical floppy (I believe diskcopy a: b: still works even with only one floppy)

              C: is the system (and programs) drive. Always RAID1 on a server. Always Ghost or equiv. backups

              D: is the CD / DVD ROM. Microsoft, by default will stack all hard drives and mount the DVD afterwards. Nothing more annoying than having it as E: on one machine and G: on another. The Microsoft Mount Manager has issues.

              E: is the data drive.

              I like to keep F: and G: free in case I mount removable media as I like H: to be the networked Home drive and the mount manager has no concept of networked or substituted drives. In other words, it will step on them and you'll get all kinds of problems. Since I like using USB2 / Firewire drives / USB memory sticks to do special work, it's nice if you have a few drive letters free below your first networked drive.

              H: is Home -- a share to another server.
              P: is Public -- a share to another server.
              X: is Xfer -- a share to another server (old school; not allowed in most places these days)
              No group drives; make a directory in P: and protect w/ ACLs

              Now I'm an old Oracle hack from way back when (Sybase and Sybase rebranded as SQL Server before that; Ingres before that; don't even want to mention anything else. Can you say IBM mainframe???

              I got out of the spindle balancing game as soon as RAID became common place so I put my data and indexes on the same logical drive. This would be E: in my "world".

              Oracle has a few special constructs that really deserve their own drive (or is it drives?): Redo logs; Archived redo logs; Temp space; Rollback segments (old) / Undo space (new).

              In my "world" these are always partitioned as "R" (Redo), "S" (Storage), "T" (Temp), and "U" (Undo).

              Regardless of whether or not I have separate arrays / drives, I still partition this way. Let me explain: I use Perfmon extensively for tuning below the database. I can look at the activity on these logical drives and profile for you what Oracle is doing I/O-wise because I'm so in touch w/ how the Beast works.

              So you have 1 array past C:. You could map the entire thing as E: (in my "world") and call it a day. Or you could look at what SQL Server has and try to map it to my "world". SQL Server combines Oracles Redo and Undo constructs into a Transaction log. Of course, SQL Server has tables and indexes (I'm telling you there is little performance gain on today's hardware to separate these). Also, there is a TempDB for joining / sorting / etc. And there is some kind of area to backup the transaction log (though this is a batch operation vs. the continuous Redo to Archived Log processing in Oracle).

              Thus my "recommendation" above C: is as follows:

              E: is the data drive. Holds the majority of the SQL Server database.
              S: is the Storage drive. Holds backups of the database.
              T: is the location for TempDB
              U: is the location for the Transaction Logs

              Change the letters as you see fit. By breaking them out like this, it becomes much easier to trend I/O by general function and determine if you need to add a separate drive / array to offload a pinch point.

              Otherwise, since you have only 1 array beyond the RAID1 System / Programs drive, go for a single E: drive.

              Buon Natale
              Last edited by rvalstar; 21st December 2006, 07:56. Reason: spelling
              Cheers,

              Rick

              ** Remember to give credit where credit is due and leave reputation points sigpic where appropriate **

              2006-2099 R Valstar. This post is offered "as is" for discussion purposes only with no express or implied warranty of any kind including, but not limited to, correctness or fitness for use. Nothing herein shall be construed as advice. Attempting any activity based on information in this post is done at your own risk.

              Comment

              Working...
              X