Microsoft FTP Publishing Service for IIS 7.0 for Windows Server 2008

File Transfer Protocol (FTP) is an old and venerable protocol, especially useful for Internet publishing. It may seem that Microsoft has not done much work on providing a robust, secure FTP. But that's all about to change. Microsoft has just created and released a new FTP service that has been completely rewritten for Windows Server 2008. This new FTP service incorporates many new features that enable web authors to publish content better than before, and offers web administrators more security and deployment options.

At first glance, the story for FTP and IIS 7.0 may seem a little confusing. In fact, there are two FTP servers available in Windows Server 2008.  One comes out of the box with either Windows Vista or Windows Server 2008, and now, we get the other as a download from the web. Why two FTP servers? Microsoft say that they ran out of time. The one that's available with Windows Vista or Windows Server 2008 is essentially the same FTP service from IIS 6.0. When you select the FTP service to install in IIS 7.0, you are actually setting up the previous IIS 6.0 Manager, in addition to the compatibility tools necessary to run it on Windows Vista or Windows Server 2008 server.

Why bother downloading a different FTP server?  Well, mostly because it seems that the new FTP server's features are compelling.  For instance, for shared hosting, it offers improvements to integrating FTP into your web site, virtual host name support and new user isolation features.  It offers support for Internet standards like IPv6, UTF8, and SSL.  And it fully integrates with IIS 7.0. This means you get a new user interface, the new XML-based configuration, and the extensibility improvements that all come built-in with IIS 7.0. This new FTP service is only for Windows Server 2008 and Internet Information Services 7.0. It will not work on Windows Server 2003 and Internet Information Services 6.0.

What are the Features of the new Windows Server 2008 FTP Publishing Server (IIS7)?

This new FTP service supports a wide range of features and improvements, and the following list contains several of the improvements in this version:

• Integration with IIS 7.0: IIS 7.0 has a brand-new administration interface and configuration store, and the new FTP service is tightly integrated with this new design. The old IIS 6 metabase is gone, and a new configuration store that is based on the .NET XML-based *.config format has taken its place. In addition, IIS 7.0 has a new administration tool, and the new FTP server plugs seamlessly into that paradigm.
• Support for new Internet standards: One of the most significant features in the new FTP server is support for FTP over SSL. The new FTP server also supports other Internet improvements such as UTF8 and IPv6.
• Shared hosting improvements: By fully integrating into IIS 7.0, the new FTP server makes it possible to host FTP and Web content from the same site by simply adding an FTP binding to an existing Web site. In addition, the FTP server now has virtual host name support, making it possible to host multiple FTP sites on the same IP address. The new FTP server also has improved user isolation, now making it possible to isolate users through per-user virtual directories.
• Extensibility and custom authentication: The new FTP server supports developer extensibility, making it possible for software vendors to write custom providers for FTP authentication. Microsoft is using this extensibility feature to implement two new methods for using non-Windows accounts for FTP authentication for IIS Managers and .NET Membership.
• Improved logging support: FTP logging has been enhanced to include all FTP-related traffic, unique tracking for FTP sessions, FTP sub-statuses, additional detail fields in FTP logs, and much more.
• New supportability features: IIS 7.0 has a new option to display detailed error messages for local users, and the FTP server supports this by providing detailed error responses when logging on locally to an FTP server. The FTP server also logs detailed information using Event Tracing for Windows (ETW), which provides additional detailed information for troubleshooting.

What are the Requirements for the new Windows 2008 Server FTP Server?

The following prerequisites must be fulfilled in order to install the new FTP server:

• You must be using Windows Server 2008 Release Candidate 0 (RC0) or later. Internet Information Services 7.0 must be installed, and the administration tool should be installed if you are going to manage the FTP server using the IIS 7.0 user interface.
• You must install the FTP server as an administrator. If User Access Control (UAC) is enabled, you must use the "Run as Administrator" option when installing.
• IIS 7.0 supports a new shared configuration environment, which must be disabled on each server in a web farm before installing the new FTP server for each node.
• Note: Shared configuration can be re-enabled after the FTP server had been installed.
• The FTP server that is shipped on the Windows Server 2008 DVD must be uninstalled before installing the new FTP server.

There are a few features that the new FTP server don't support. For example, there is no support for SFTP (FTP over SSH). You can't delegateFTP  configuration, like you can with many other IIS 7.0 features. And there is no support for Windows Server 2003 or earlier operating systems.

3 Ways to Enable the Built-In Windows 7 Administrator Account

In Windows 7, like Windows Vista, when you install the operating system, you are asked to enter a user name which will be the primary local user that will use this system.

Like in Windows Vista, in Windows 7 the built-in Administrator's account is disabled by default. Furthermore, this account is not associated with any password.

The new user which is created during the installation is configured to be a member of the built-in Administrators group, and in fact, can be used for any management task. That use is in fact equivalent by all means with the original built-in Administrator account.

However, there may be situations where one would like to use the built-in Administrator account instead of that "new" user. One of these might be when you're building a system for cloning purposes, and would like all cloned machines to be able to use the built-in Administrator's account.

Note that since that account does NOT have a password, enabling it without properly setting a password for that account will open a serious security opening on your system!

There are basically 2 easy methods of enabling the built-in Administrator's account and 1 advanced method.

Method #1 - Using the Local Users and Groups Snap-in

To enable the built-in Administrator's account by using the Local Users and Groups snap-in please follow these steps:

Open Local Users and Groups. You can do so by typing lusrmgr.msc in the Start search box or in the Run command and pressing ENTER. Or, you could open Computer Management by right-clicking Computer in the Start menu and selecting Manage.

Expand System Tools > Local  Users and Groups > Users.

Right-click the Administrator account and select "Set Password".

In the"Set Password for Administrator" click "Proceed".

In the"Set Password for Administrator" enter the Administrator's desired password twice, and click "Ok".

Next, enable the Administrator's account. Right-click the Administrator's account and select "Properties".

Un-chek the "Account is disabled" check-box. Click on the "Ok" button.

Administrator's account is now enabled and configured with a password.

Method #2 - From the Command Prompt

To enable the built-in Administrator's account by using the Command Prompt  please follow these steps:

1. Click Start and type CMD, then press Enter. It is best to run the Command Prompt as an Administrator. To do so, right-click CMD and select "Run as Administrator".

When prompted to allow the Command Processor to run, click on "Yes".

BTW, you can also hover over the CMD line and press CTRL + SHIFT + ENTER to invoke the "Run as Administrator" shortcut.

In the Command Prompt window, type:

net user

Note how the Administrator account is there, yet the new user account has not been yet created.

To set the Administrator's account password:

net user *

Then enter the required password and confirm it.

To enable the Administrator's account:

net user administrator /active:yes

Method #3 (Advanced Users) - During the Installation Process

There is a 3rd method which advanced users can use. This method can be used during the installation process itself.

During the installation, after being prompted to configure the new user account, you will be able to set the new account's password.

At that phase, press SHIFT and F10 keys together. A Command Prompt window will appear.

In the Command Prompt window, type:

net user

Note how the Administrator account is there, yet the new user account has not been yet created.

To set the Administrator's account password:

net user *

Then enter the required password and confirm it.

To enable the Administrator's accoun:

net user administrator /active:yes

Close the Command Prompt window and continue with the installation process.

If you log off you will now see the Administrator's account as a valid logon option.

Join a Domain in Windows 7

Joining your machine to a domain will let you enjoy the domain's benefits, such as scalability, central management, Group Policies, security and more.

Prerequisites

Before joining your Windows 7 machine to a domain, make sure you properly understand the following prerequisites:

Use Windows 7 Professional, Ultimate or Enterprise - Only Windows 7 these editions can join a domain. No, Windows 7 Home can't. Don't try it.

Have a  network Interface Card (NIC) - Duh, but unless you have one (or a wireless connection) how do you expect to connect to the server?

Be physically be connected to the LAN - Windows 7 (and previous OSs) has an LAN auto sensing feature. Whenever you disconnect from the network, a balloon appears in the tray area notifying you of the disconnection status. Note that Windows 7 can be joined in an offline mode to a Windows Server 2008 R2 domain, but that's a topic for a different article.

Have a valid IP address - Valid for the network you're connected to. You can either configure one manually, receive one from a local DHCP Server, or leave it as is and receive an APIPA address (whatever starts with 169.254.X.Y). If it's an APIPA address you're asking for potential problems, as APIPA and AD do not go together hand-in-hand.

Have all-time connectivity to the Domain Controller - Or at least one of them. The IP address you've configured (or leased) should be good enough to enable you to connect to one of the Domain Controllers on your Domain. You may test your connectivity with PING, but make note that a successful PING does not guarantee that you've got proper connection to the DCs.

Have a properly configured DNS server - Without a properly configured DNS server your workstation will not be able to connect to the domain. Even if it did (for example you had a working DNS server but you somehow messed it up or shut it down) it will take a lot of time to actually log-on, and many AD related administration tasks will not work. The DNS server must hold a zone with the exact name of the AD domain you're trying to join. It also must hold 4 SRV folders (you can tell by the "_" in their name). If it doesn't, you either misspelled the domain name or DNS zone, or the zone is not configured to accept dynamic registrations, or it's not a Windows 2000/2003/2008 DNS server, or the Domain Controller does not have a working connection with the DNS server (firewall problems, improper IP configuration, IPSec etc.)

Have all-time connectivity to the DNS server - Test your connection to the DNS server by PINGing it and performing an NSLOOKUP query.

Possess local Administrative power - A simple user won't do. You must be the local Administrator.

Know the correct domain name, Administrator's name and password - Misspelled your domain name? You won't get to the Username and Password prompt!

Got your domain name right? You'll be asked for a valid username and password. To be safe, enter one that has Domain Admins rights, although you could get away with less, depending on your AD configuration (by default, any domain user has the right to join up to 10 machines to the domain. But this setting may have been altered by the domain admin).

You can perform the preceding tasks by using the Computer Name tab in the System Properties dialog box from the Control Panel or by right-clicking My Computer, and then Properties or by pressing the Windows logo key and Break. You may also use the NETDOM command. I will cover both methods.

Method #1 - The Traditional Way

1. Open System by clicking the Start button, right-click "Computer", and then click "Properties".

2. Under "Computer name, domain, and workgroup settings", click "Change settings".

Actually, you can also click on "Advanced system settings" and click on the "Computer Name" tab.

A third method to get to the same place is to use the Control Panel. Type "Domain" in the search box, then click on "Join a domain" link.

Either way, you're there. If you're prompted for an administrator password or confirmation, type the password or provide confirmation.

3. Click the Computer Name tab, and then click "Change".

4. Under Member of, click Domain.

5. Type the name of the domain that you want to join, and then click OK.

You will be asked to type your user name and password for the domain.

Once you are successfully joined to the domain, you will be prompted to restart your computer. You must restart your computer before the changes take effect.

Alternatively, you can click "Network ID" to use the Join a Domain or Workgroup wizard to automate the process of connecting to a domain and creating a domain user account on your computer. This is a longer way and I'm not sure why people would want to use it, but I'll document it anyway.

Go through the steps of the wizard. Make sure you select "This computer is part of a business network".

Then select "My company uses a network with a domain".

Provide the domain name and proper credentials.

And again.

You will still need to restart when the wizard is done.

Method #2 - Using NETDOM

By using NETDOM you can accomplish the task of joining a domain from the command prompt, and do it all in one line.

NETDOM is now included in the core OS, unlike Windows 2000/XP/2003 where you had to install the Support Tools to get it.

Open a Command Prompt window with Administrative credentials and type the following line:

Notes: Replace DOMAIN.COM and DOMAIN with your correct domain name, and of course, enter the proper user credentials. Also note there's an additional "d" in "user" and "password", that is NOT a typo.

netdom join %computername% /domain:DOMAIN.COM /userd:DOMAIN\administrator /passwordd:P@ssw0rd

Reboot the computer to complete the process.

List all Users and Groups in Domain

There are many tools and utilities designed to do so, but none are native W2K GUI. There are no graphical or command line utilities that produce comprehensive reports on groups, users and permissions included with the Windows Operating System or the Resource Kit. The NET commands and the Windows Resource Kit ADDUSERS.EXE and PERMS.EXE utilities can be used to create limited administrative reports by piping the output to a text file.

Limited report generation is possible through the following commands:

Note: Removal of the /domain switch will generate a report for the local machine.

NET USERS /DOMAIN >USERS.TXT

This command will return the user accounts from the Primary Domain Controller (PDC) of the current domain, and write them to a file called USER.TXT

NET ACCOUNTS /DOMAIN >ACCOUNTS.TXT

This command will return the account policy information from the PDC of the current domain, and write it to a file called ACCOUNTS.TXT

NET CONFIG SERVER >SERVER.TXT

This command will return the server name, version of Windows, active network adapter information/MAC address, Server hidden status, Maximum Logged On Users, Maximum open files per session, Idle session time, and assign it to a file called SERVER.TXT

NET CONFIG WORKSTATION >WKST.TXT

This command will return the workstation name, user name, version of Windows, network adapter, network adapter information/MAC address, Logon domain, COM Open Timeout, COM Send Count, COM Send Timout, and write it to a file called WKST.TXT.

NET GROUP /DOMAIN >DGRP.TXT

This command will return the global groups on the PDC of the current domain, and write them to a file called GRP.TXT.

NET LOCALGROUP >LGRP.TXT

This command will return the local groups on the local machine, and write them to a file call LGRP.TXT.

NET VIEW /DOMAIN:DOMAINNAME >VIEW.TXT

This command will return the resources in the specified domain, and write them to a file called VIEW.TXT.

Using Resource Kit Tools

ADDUSERS \\COMPUTERNAME /D USERINFO.TXT

This Windows Resource Kit command will return a comma delimited file (for spreadsheets) containing user and group information, and write it to a file called USERINFO.TXT.

PERMS COMPUTERNAME\USERNAME C:\*.* /S >PERMS.TXT

This Windows Resource Kit command will return the username permissions on all files in all subdirectories on the c:\ drive of the computername, and write it to a file called PERMS.TXT

In addition to these user management tools, there are many tools and scripts out there to help in querying, creating, modifying and deleting user objects in the directory. You should explore the Support Tools from the Windows 2000 product CD and the Windows 2000 Resource Kit to get acquainted with some of them at least, since they can really ease your work sometimes. Here is a quick description of some of those tools:

The Windows 2000 Resource Kit offers us some scripts for handling users:

ClassifyMembers.vbs

Will list objects in a container/OU or a domain.

ListProperties.vbs

This script can be used with the WinNT:// namespace against Windows NT, Member or Workstation machines, or with the LDAP:// namespace for Active Directory Domain Controllers. Pay attention that this script is case-sensitive in its syntax.

As for enumerating group membership, there are several tools, such as:

FindGrp.exe IfMember.exe ShowGrps.exe

Each gives different results, so you might want to run them and compare the outputs of each tool. ShowGrps.exe, for example, can also query for group membership of computer objects:

FindGrp.exe <Domainname>\<MachineName>$

If you want to search for users satisfying a given criteria, you can try out

chkusers.vbs

This script checks your domain for users that satisfy a certain criteria that you define. For example:

Cscript CHKUSERS.VBS /A:WinNT://YourDomainName /P:FullName;Description /C:"((LastLogin:>4/3/01 or LastLogin:<8/4/01) and AccountDisabled:=False)"

This will output the full name and description of all active users whose last login was between 4/3/01 to 8/4/01.

Using LDIFDE

From the support tools we can find LDIFDE.exe, which is a tool for bulk import and export of Active Directory Objects. You can use LDIFDE to import new user records into the directory, or export specific information on specific users into a text file. LDIFDE defaults to export mode (reading From the Directory). When you add the -i option it can be used to write changes into the Directory. Also, if you want to export and extract only specific details, such as the user name, title and login name for all the users in a specific OU (Organizational Unit), you can run the following command:

ldifde -f C:\ldif\ExportUsers.ldf –s SERVERNAME -d "OU=YourOUname,dc=YourDomainName,dc=com" -p subtree -r "(objectClass=User)" -l "cn,givenName,Title,SamAccountName"

Remotely Manage Devices in Windows 2008 Server Core

Server Core installation provides a minimal environment for running specific server roles, which reduces the maintenance and management requirements and the attack surface for those server roles. You can read more about Server Core in the "What's Related" section at the bottom of this page.

Getting to the point of this article, remotely managing Server Core is not as hard as it seems. You can read more about it on several of my articles, but the point is that most things can be done remotely by using the regular MMC-based snap-in Administration tools, WinRM and WinRS, and even through Remote Desktop.

This article focuses on remote administration via the MMC-based Administration tools. In order to get these to work across the network you will need to run the following command on the server core machine (or on any other Windows Server 2008 server for that matter):

netsh advfirewall firewall set rule group="remote administration" new enable=yes

The above command will allow for most remote management tools to work out-of-the-box. However, in addition to allowing the MMC snap-ins through the firewall, using Device Manager remotely requires additional configuration. If you don't perform the following steps you will end up with this error:

Running Device Manager remotely

To allow Device Manager to connect to a remote computer, you must first enable the "Allow remote access to the PnP interface" setting on the target computer's Local Group Policy.

1. On a Windows Vista or Windows Server 2008 installation, start the Group Policy Object MMC snap-in by typing MMC in the Run box and pressing Enter.

2. In the Add or Remove Snap-Ins window, scroll to find Group Policy Object Editor, and click Add.

3. In the Select Group Policy Object window, click Browse.

4. In the Browse for Group Policy Object window, click Another Computer, and either type or browse for the remote server core machine.

5. In the Select Group Policy Object window, click Finish.

6. In the Add or Remove Snap-Ins window click Ok.

7. In the Group Policy of the remote computer, navigate to Computer Configuration -> Administrative Templates -> System -> Device Installation.

8. Enable the Allow remote access to the PnP interface setting.

9. Close the MMC console (you don't have to save it, but you can if you want to).

10. Restart the Server Core installation.

Now you can connect to the remote server core machine and manage its devices by using Device Manager.

1. Open Computer Management through the Administrative Tools folder.

2. Right-click Computer Management and select Connect to another computer.

3. In the Select computer window, type or browse to the remote server core computer. Click Ok.

4. Expand System tools -> Device Manager. Note that now you can perform changes on the listed devices.

And that's it! You are done!

Plan your Exchange 2007 Backups based on Server Roles

When Microsoft created Exchange Server 2007, one of the biggest
changes that they made was the creation of server roles. The concept
of roles existed in Exchange server 2003, it was very limited. In
Exchange server 2007, there are five different roles which serve five
very specific purposes.

Because these roles are so different from one another, the tasks that
an Exchange Server performs, and the code that is installed is
entirely dictated by the role that the server is configured to
perform. That being the case, it is necessary to completely reevaluate
your backup strategy. The backup techniques and procedures that
Exchange admins have used for so long are not always the best option
in an Exchange Server 2007 environment. In this article, I will
discuss some backup strategies for each of the various Exchange 2007
server roles.
Mailbox Server

Like its predecessors, Exchange Server 2007 stores user's mailboxes in
a jet database (now called an extensible storage engine database). For
all practical purposes, backing up a mailbox server in Exchange Server
2007 is really no different than backing up an Exchange 2003 server.
That being the case, I want to focus the majority of my discussion on
the other server roles.
Hub Transport Server

As I'm sure you probably know, a hub transport server's primary job is
to route messages within the Exchange Server organization. At first
glance, it would appear that it would be appropriate to use the same
backup technique for a hub transport server as you would use for a
mailbox server. After all, a hub transport server contains all of the
message queues, and then Exchange Server 2007, the queues are based on
a jet database that is very similar to the ones used by mailbox
servers.

In spite of this though, Microsoft actually recommends that you do not
backup hub transport servers in the traditional manner. This is
primarily because of the transient nature of the messaging queues.
Suppose for a moment that you made a backup of the hub transport
server, and 15 minutes later the server failed catastrophically. It
wouldn't really do you any good to restore the database used by the
message queues, because all of the messages that were in the queues at
the time that the backup was made would have already been delivered.

Not only is it not necessary to backup the message queues, you really
don't have to worry about backing up the server's configuration
either. The vast majority of the configuration information is stored
in Active Directory. If you find yourself having to rebuild a hub
transport server, you can simply run Setup with the
/Mode:RecoverServer switch. This command will use information
contained in the Active Directory to rebuild the server. You can read
more about this command at Microsoft Technet.
Edged Transport Servers

Although it's transport servers are designed to be isolated from the
rest of your Exchange Server organization, they are architecturally
very similar to hub transport servers. In fact, it's transport servers
use queues that are based on the extensible storage engine just like
hub transport servers do. Like hub transport servers, it is
impractical to try to back up these queues.

Assuming that you are running a default configuration, you may not
even need to worry about backing up an edge transport server. After
all, Microsoft automatically updates the ant spam information over the
Internet.

There are two cases though that weren't backing up an edge transport
server. One such situation would be cases in which you want to retain
your message tracking and protocol logs. If you need to back up these
logs, you can perform a simple file level backup. Incidentally, the
same thing goes for hub transport servers.

The other situation that would warrant backing up an edge transport
server is that you would want to create a backup if you were using
custom filtering settings. If you are using custom filtering settings,
you'll have to use a predefined script to export those settings to an
XML file. You can then back that XML file up using a normal file level
backup. Should you ever need to restore the settings, you simply
import the XML file using another predefined script. In case you're
wondering, these scripts are called ExportEdgeConfig.ps1 and
ImportEdgeConfig.ps1. Both of these scripts are located in the
\Program Files\Microsoft\Exchange Server\Scripts folder.
Client Access Servers

Backing up and restoring client access servers can be pretty tricky.
Like a hub transport server, you can rebuild a client access server by
entering the SETUP /MODE:RecoverServer command.

The problem is that entering this command returns the client access
server to a default state. Even if you have created non-default
virtual directories, those directories will be wiped out after using
this command. Unfortunately, entering this command and then restoring
a backup isn't really an option because doing so will cause the IIS
Metabase to be out of sync with the Active Directory. As such,
Microsoft recommends that you make a log of all of the custom changes
that you apply to your server. You can use the Setup command to
rebuild the server, and then manually reapply your customizations.

If you decide to perform a traditional backup, then you must design
the backup to include system state data.
Unified Messaging Servers

As I'm sure you probably know, unified messaging servers allow you to
store voice mail and faxes in Exchange Server mailboxes. Assuming that
your unified messaging server is running a default configuration, you
don't have to worry about backing it up. All of the essential
configuration data is stored in the Active Directory, and you can
easily rebuild a unified messaging server by using the SETUP
/MODE:RecoverServer command.

There is one exception to this rule though. If you have configured
your unified messaging server to use custom voice prompts, then you
will need to perform a file level backup to ensure that those voice
prompts are backed up. In case you're wondering, voice prompts are
stored in the \Program Files\Microsoft\Exchange Server\Unified
Messaging\Prompts folder.

How to Plan SQL Server Database Files

One of the most important tasks you can do in SQL Server is to setup
your data and log files. Not getting these files setup correctly can
be one of the biggest causes for production problems whether it's disk
contention, space usage, or something else. And honestly this level
of planning is often overlooked and by the time the problem is
discovered the application and its users have already suffered. So
let's get into some good discussion about how to setup your database
files.

Log files

We're going to start with logs first because they're the easiest and
probably the ones you'll touch most frequently. And we need to talk
about placing your log files on disk first. In general, you'll want
to place your log files on a different physical partition than your
data files. This is for 2 reasons. The first is disk contention.
Every transaction has to write something to the log file before it can
write it to the data file and if both files are on the same disk, then
the disk arm has to work twice has hard because it has to jump over
here to write the log and then jump over there to write to the table.
Putting a log file on its own disk is also better for the performance
of the log because logs write sequentially so if the log file is on
its own disk the disk arm has very little moving to do to get to the
next place it needs to write so it's much faster. The second reason
you want data and log files on separate disks is for recovery. If the
data partition fails you'll want the log on a separate set of disks so
you can still recover the logs and roll the last transactions forward
so you don't lose any data.
Several log files

It's a common misconception that you will get a performance gain by
using several log files. This is something we see quite often and it
simply isn't true. Log files are written sequentially which means
that each log file is filled up before the next one is written to. So
if you have 4 log files (Log1, Log2, Log3, Log4), SQL Server 2008 will
fill up Log1, then fill up Log2, etc. This is different from the way
data files behave and we'll discuss that in a minute. The only reason
to have multiple log files on multiple partitions is for space. You
may need more disk than a single partition can provide. Oh, and
putting multiple log files on a single partition is just dumb. It
gains you nothing.
Data files

Now let's talk about where you'll place your data files. As we've
already said it's a good idea to place them on a different physical
partition from your log files. And we know we already said that, but
experience has shown us that we could fill an entire page with that
exact advice and a good portion of you still won't grasp the
importance of it. So we're really going to hammer that point home in
this article.

So while your data files are separated from your log files you may
feel free to have multiple data files on multiple physical partitions
to take advantage of performance gains. Now, we have to say again
that these have to be physical partitions because logical partitions
are still on the same physical disk and it's the disk arm contention
you're trying to avoid. Data files, unlike log files, use what's
known as an equal fill algorithm. This means that all of the files
are filled equally as much as possible. So let's say you have 4 data
files (Data1, Data2, Data3, Data4). When you write to the database,
SQL Server 2008 will write to these files in a round robin fashion and
they should grow at more or less the same rate. You can also place
tables inside specific files so you have a good level of control over
how you split up the I/O workload in your database. And while the
number of files you need to optimize your workload is a subject that's
up for debate in the community, for most systems it won't make that
much difference. However, it is a good idea that no matter how many
data files you decide to have, to make them all the same size. This
goes back to that equal fill algorithm we were talking about before.
File growth

Another good topic is file growth. This is a mistake that many
beginners make. They accept the defaults for file growth and that's
just asking for trouble. We're going to give you some advice on how
to set your file growth and you can adjust it to suit your needs, but
at least you'll know the arguments.

1. The best thing to do is to set both your data and your log files
as large as you ever want them to be. Depending on your version of
SQL Server, it can be very expensive to grow files so setting their
size ahead of time can alleviate performance problems before they even
start. So if you've got a single partition dedicated to your log
file, then go ahead and make your log the same size as your partition.
If it's dedicated then you've got nothing to lose. And the same goes
for your data files. If they're on dedicated partitions (and they
should be), then you've got nothing to lose.
2. The next best thing is to set your files to autogrow by fairly
large predictable increments. The default autogrowth is 1MB for data
files and 10% for log files. I always grow data files by at least 1GB
and often times even more. If you're going to suffer the expense of
growing a file you don't want to do it 5 times a day, so make it worth
your while. And 10% is too unpredictable. As the log grows the 10%
marker is going to get bigger too so you'll actually be growing your
log more and more each time.
3. Set all your data files to grow at the same rate, and all of
your log files to grow at the same rate. Your data files don't have
to grow at the same rate as your log files, but they should grow at
the same rate as each other.

Here we talked about separating your data and log files onto separate
partitions, as well as some of the theories on why we recommend the
things we do. In the next article, How to manage SQL Server database
files, we'll talk about how to physically change your file properties
to accomplish these goals. And don't forget to separate your data and
logs onto separate physical partitions.