Installing SQL Server Express 2008

Notice:

We do proceed as in the precededing stage, selecting the New SQL Server stand-alone installation or add feature to an existing installation, with all the same steps, but this time we are to select the installation of a the database engine service for a new named instance

In the Instance configuration dialog we can start customizing our requirements, specifying the instance name as well as the instance ID and the position on the file system for all relative binaries

Soon after the space check for the required files to be installed, we are required to define all the service's security configuration, providing the account context that will execute the service.
In order to conform to security best practices as well as Microsoft warnings and advices not to use special powerfull system accounts like Local System and the like, we do hereby generate a brand new limited local account to be used for the case

This new limited local account will be responsible for the security execution context of the database engine instance's service.
We plan not to use the SQL Browser service, required for dynamic TCP/IP port assignements, as we will later provide a static manual assigned TCP/IP port for remote connections. This choice will enable us to further limit the surface attack area as we will not be required to open the UDP 1434 port required by SQL Browser service.

In the Collation panel we can customize, if required, the relative settings.
We do personally prefer Windows collation based collations over the default presented SQL Collation, so we are modifying the default proposal from SQL_Latin1_xxx to a Windows based collation, in this case Latin1_General case insensitive accent sensitive

Our current scenario is very simple, but we do want to allow standard SQL Server authenticated connections as well as more secure Windows authenticated connections so we have to enable Mixed mode authentication, providing a strong sa logins' password. Windows authenticated connections, as known as trusted connections are the default settings as they are more secure. No sensitive trafic is performed between the client and the server, and only a SID (security id) is requested with a round trip to the Domain Controller available on the LAN, so no actual sniffing can be performed to hack a SQL Server instance. SQL Server will then only verify the connecting Windows account/group has been granted connect permissions to the instance.
On the contrary, standard SQL Server authenticated connections require a complete transmission of credentials, UserID and password. SQL Server will validate those credentials agains the internal SQL Server logins list and eventually grants connection execution.
In both circumstances, this is the very first security phase.
We are asked if we like to add some Windows user/group to the SQL Server's administrators server role, and so we do as required, but please keep in mind to keep that list very short :)

Default settings for file system entries do not require our intervention,

but we like to enable the new FILESTREAM features available in this version, making them available to remote users via NTFS APIs as well

Ordinary space and further installation rules check are performed, and we are reported with the final report of the installation to be

There's an interesting entry in this summary, relative to the SQL Server agent component.
SQL Server Agent is now part of every SQLExpress installation, but unfortunately, it will not be available and the relative service will not be startable as well.
This does not change the automation tasks set as defined for SQLExpress 2005, and we still have to rely on other schedulers than the native SQL Server Agent scheduler.

As the precedent installation already registered a lot of stuff, this one is very quick and after quiet 5 minutes we are reported with it's success

later confirmed by

We are curious guys, and we goring to check our system for the performed changes;
Add remove programs system applet does not help a lot for this hunt, as there are quiet minimal changes

but the installed service applet confirms our hope to se the installed instance

and the very same confirmation comes at the file system level

Having the named instance installed, we are ready to configure and set that instance via SQL Server Configuration Manager.
We are going to allow remote connections over TCP/IP network protocol, and define a static port for the service to listen on, instead a dynamically assigned one.
Changing these settings will require us to restart the service, as the tool gracefully reminds.

We can finally access the installed instance via the previously installed SQL Server Management Studio Basic

and we are immediately gratified with an instance version confirmation, so it's time to configure additional settings for the current instance.
These are not standard settings, and they all are disabled dy default, following the secure by design philosiphy.
To fit our requirements, we have to enable CLR integration and xp_cmdshell extented stored procedure, and eventually disable User Instances.
To fulfill these requirements we have to rely on a new feature available in the Management Studio, the facets

Back monitoring our system we can verify the hard disk has been loaded with about 900Mb

and Task Manager confirms the system has been loaded, but not overloaded, by this installation as repoted by