Net Data Design, LLC Blog

An alternative method of installing DotNetNuke on IIS 7.5 9or IIS 7) is using the free helper application by Mike van der Meulen. MakeDNNSite is a nice little package that will give you a new DNN install without a lot of hassle. There is no manual web.config editing, Application Pool creating or setting of permissions (see note below). It will even download the latest build for you or use a package that you already have downloaded.

I have used this method several time in testing and found it to be flawless (2008 R2, 64-bit). It does come with a few restriction, such as you can’t install using a sub-domain. It said to work on IIS 7 and 7.5 both 32-bit and 64-bit and SQL Server 2005 and 2008 both full and Express editions.

Because MakeDNNSite works on both IIS 7 and 7.5, the Application Pool created uses the NetworkService account. While this is fine for IIS 7, however it is not the preferred account for IIS 7.5, rather the IIS AppPool Idently account should be used. This can be simply changed by right-clicking the newly created AppPool and selecting ‘Advanced Setting’. There, under Process Model, change the identity to ‘ApplicationPoolIdentity’.

If you opt to use the ApplicationPoolIdentity you will need to update you permissions on the website directory as well. I have blogged about this in detail (IIS 7.5 AppPool Identities).

In short, it’s a really nice tool at a great price (Free.) I highly recommend it for all DNN users, regardless of your environment or skill level.

There have been many questions on how to install and configure DotNetNuke on IIS 7.5 which ships in Windows 7 and Windows 2008 R2. I will outline the procedure I use to do so. For this example I will be using Windows 2008 R2 64-bit.

When you first login to 2008 R2 you will be greeted with the Server Manager.

After you expand the Roles node and the Web Server node in the left pane you will be in the main IIS Manager.

Right Click on the “Sites” folder and select “Add Web Site.”

In the next screen we enter the web sites specifics. Fill in the highlighted areas with your information. Note that as you enter your site name an new Application Pool is created.

During the above process you will create a new directory to which you will deploy your DNN code.

After this is complete, select Application Pools from the IIS Manager node. The detailed view should indicate that the AppPool is in Integrated Pipeline mode.

If you have not already done so, copy your DNN files to your website directory. In IIS Manager right click your new website and:

1. Select “Edit Permissions.”
2. Select the “Security” tab.
3. Click the “Edit” and then “Add” button
4. Click the “Locations” button and make sure you select your machine.
5. Enter “IIS AppPool\<YourAppPoolName>” in the “Enter the object names to select:” text box.
6. Click the “Check Names” button and click “OK”.
7. Grant <YourAppPoolName> modify permissions on the directory.

At this point you are ready to edit your web.config for your database connection., and get started.

If you have any questions on the Application pool details, I have covered this in an earlier Blog, you can read that here.

Windows 7 and Windows Server 2008 R2 ship with IIS 7.5. It’s called Application Pool Identities. Application Pool Identities allows you to run Application Pools under an unique account without having to create and manage domain or local accounts. The name of the Application Pool account corresponds to the name of the Application Pool. The image below shows an IIS worker process (w3wp.exe) running as the DefaultAppPool identity.

Application Pool Identity Accounts

Worker processes in IIS 6 and 7 run as NETWORKSERVICE by default. NETWORKSERVICE is a built-in Windows identity. It doesn’t require a password and it has only user privileges, i.e. it is relatively low-privileged. Running as a low-privileged account is a good security practice because then a software bug can’t be used by a malicious user to take over the whole system.

The problem is however that over time more and more Windows system services started to run as NETWORKSERVICE and services running as NETWORKSERVICE can tamper with other services running under the same identity. Because IIS worker processes run third-party code by default (Classic ASP, ASP.NET, PHP code) it was time to isolate IIS worker processes from other Windows system services and run IIS worker processes under unique identities. The Windows operating system provides a feature called “Virtual Accounts” that allows IIS to create unique identities for each of its Application Pools. Click here for more information about Virtual Accounts.

Configuring IIS Application Pool Identities

If you are running IIS 7.5 on Windows Server 2008 R2 you don’t have to do anything. For every Application Pool you create the IIS Admin Process (WAS) will create a virtual account with the name of the new Application Pool and run the Application Pool’s worker processes under this account.

If you are running Windows Server 2008 you have to change the IdentityType property of the Application Pool you created to “AppPoolIdentity”. Here is how:

• Open the IIS Management Console (INETMGR.MSC).
• Open the Application Pools node underneath the machine node. Select the Application Pool you want to change to run under an automatically generated Application Pool Identity.
• Right click the Application Pool and select “Advanced Settings…”

• Select the “Identity” list item and click the button with the three dots.
• The following dialog appears.

• Select the Identity Type “ApplicationPoolIdentity” from the combo box

To do the same step via command-line you can simply call the appcmd command-line tool the following way:

%windir%\system32\inetsrv\appcmd.exe set AppPool <your AppPool> -processModel.identityType:ApplicationPoolIdentity

Securing Resources

Whenever a new Application Pool is created the IIS management process creates a security identifier (SID) representing the name of the Application Pool itself, i.e. if you create an Application Pool with the name “MyNewAppPool” a security identifier with the name “MyNewAppPool” is created in the Windows Security system. From this point on resources can be secured using this identity. The identity is not a real user account however, i.e. it will not show up as a user in the Windows User Management Console.

You can try this by selecting a file in Windows Explorer and adding the “DefaultAppPool” identity to its Access Control List (ACL).

1. Open Windows Explorer
2. Select a file or directory.
3. Right click the file and select “Properties”
4. Select the “Security” tab
5. Click the “Edit” and then “Add” button
6. Click the “Locations” button and make sure you select your machine.
7. Enter “IIS AppPool\DefaultAppPool” in the “Enter the object names to select:” text box.
8. Click the “Check Names” button and click “OK”.

By doing this the file or directory you selected will now also allow the “DefaultAppPool” identity access.

You can do this via the command-line using the ICACLS tool. The following example gives full access to the DefaultAppPool identity.

ICACLS test.txt /grant “IIS AppPool\DefaultAppPool”:F

On Windows 7 and Windows Server 2008 R2 the default is to run Application Pools as this security identifier, i.e. as the Application Pool Identity. To make this happen a new identity type with the name “AppPoolIdentity” was introduced. If the “AppPoolIdentity” identity type is selected (default on Windows 7 and Windows Server 2008 R2) IIS will run worker processes as the Application Pool identity. With every other identity type the security identifier will only be injected into the access token of the process. If the identifier is injected content can still be ACLed for the AppPool identity but the owner of the token is probably not unique. Here  is an article that explains this concept.

Accessing the Network

Using the NETWORKSERVICE account in a domain environment has a great benefit. Worker process running as NETWORKSERVICE access the network as the machine account. Machine accounts are generated when a machine is joined to a domain. They look like this:

<domainname>\<machinename>$,

for example:

mydomain\machine1$

The nice thing about this is that network resources like file shares or SQL Server databases can be ACLed to allow access for this machine account.

What about AppPool identities?

The good news is that Application Pool identities also use the machine account to access network resources. No changes are required.

Note:

This article http://learn.iis.net/page.aspx/246/using-fastcgi-to-host-php-applications-on-iis-70/ walks you through the process. This article was written for IIS 7, but will apply to IIS 7.5 as well.

In addition, if your server is 64 bit, you should set ‘enable 32 bit applications‘ to true in your application pools settings.

Mentioned in my previous two posts, Smooth Streaming  is Microsoft’s completion of HTTP-based adaptive streaming, which is a truly a hybrid media delivery method. It may act like streaming, but it is in fact based on HTTP progressive download. The HTTP downloads are performed in a series of small chunks, allowing the media to get easily and cheaply cached along the edge of the network, closer to the end users. The Expression Encoder provides multiple encoded bitrates of the same media source also allows Silverlight clients to seamlessly and dynamically switch between bitrates depending on network conditions and CPU power. The end users experience is one of reliable, consistent playback without stutter, buffering or “last mile” pipe-line clog.

A Microsoft media format and no ASF? That’s right. Why MP4 and not ASF? Well, here are a few reasons:
•    MP4 is a lighter container and uses less overhead.
•    MP4 are easier to “digest” by .NET.
•    MP4 is more widely supported.
•    MP4 was architected with H.264 video codec support, although ASF can be as well, it’s not as native.
•    MP4 was designed to natively support payload fragmentation

There are actually two parts to the Smooth Streaming format: the wire format and the disk file format. In Smooth Streaming, a video is recorded in full length to the disk as a single file (one file per encoded bit rate), but it’s transferred to the client as a series of small file chunks. The wire format defines the structure of the chunks that are sent by IIS to the client, whereas the file format defines the structure of the contiguous file on disk, enabling better file management. Fortunately, the MP4 specification allows MP4 to be internally organized as a series of fragments, which means that in Smooth Streaming the wire format is a direct subset of the file format.

So exactly what are these “fragments”? The basic unit of an MP4 file is called a “box.” These boxes can contain both data and metadata. The MP4 specification allows for various ways to organize data and metadata boxes within a file. In most media scenarios, it’s considered useful to have the metadata written before the data so that a player client application can have more information about the video/audio that it’s about to play before it plays it. However, in live streaming scenarios it’s often not possible to write the metadata up-front about the whole data stream because it’s simply not yet fully known.

The following figure is a high-level overview of what a Smooth Streaming file looks like on the inside:

In a nutshell, the file starts with file-level metadata (‘moov‘) which generically describes the file, but the bulk of the payload is actually contained in the fragment boxes which also carry more accurate fragment-level metadata (‘moof‘) and media data (‘mdat‘). (The diagram only shows 2 fragments, but a typical Smooth Streaming file has a fragment per every 2 seconds of video/audio.) Closing the file is a ‘mfra‘ index box which allows easy and accurate seeking within the file.
When a Silverlight client requests a video time slice from the IIS Smooth Streaming server, the server simply seeks to the approriate starting fragment in the MP4 file and then lifts the fragment out of the file and sends it over the wire to the client. This is why we refer to the fragments as the “wire format.” This technique greatly enhances the efficiency of the IIS server because it requires no remuxing or rewriting overhead.
Here is what an MP4 fragment looks like in more detail:

We say that the Smooth Streaming format is based on the MP4 file format because even though we’re following the ISO specification, we specify our own box organization schema and some custom boxes. In order to differentiate Smooth Streaming files from “vanilla” MP4 files, we use new file extensions: *.ismv (video+audio) and *.isma  (audio only). I keep forgetting to ask the IIS Media team what the acronyms exactly stand for, but my best guess would be “IIS Smooth Streaming Media Video (Audio)”.

Smooth Streaming Media Assets

A typical Smooth Streaming media asset therefore consists of the following files:

• MP4 files containing video/audio
  • *.ismv – contains video and audio, or only video
    • 1 ISMV file per encoded video bitrate
  • *.isma – contains only audio
    • In videos with audio, the audio track can be muxed into an ISMV file instead of a separate ISMA file
• Server manifest file
  • *.ism
  • Describes the relationships between media tracks, bitrates and files on disk
  • Only used by the IIS Smooth Streaming server – not by client
• Client manifest file
  • *.ismc
  • Describes to the client the available streams, codecs used, bitrates encoded, video resolutions, markers, captions, etc.
  • It’s the first file delivered to the client

Both manifest file formats are based on XML. The server manifest file format is based specifically on the SMIL 2.0 XML format specification.

A folder containing a single Smooth Streaming media asset might look something like this:

In this particular case the audio track is contained in the NBA_3000000.ismv file.

Smooth Streaming Manifest Files

The Smooth Streaming Wire/File Format specification defines the manifest XML language as well as the MP4 box structure. Because the manifests are based on XML they are highly extensible. Among the features already included in the current Smooth Streaming format specification is support for:

• VC-1, WMA, H.264 and AAC codecs
• Text streams
• Multi-language audio tracks
• Alternate video and audio tracks (i.e. multiple camera angles, director’s commentary, etc.)
• Multiple hardware profiles (i.e. same bitrates targeted at different playback devices)
• Script commands, markers/chapters, captions
• Client manifest Gzip compression
• URL obfuscation
• Live encoding and streaming

Smooth Streaming Playback: Bringing It All Home

Microsoft’s adaptive streaming prototype (used for NBC Olympics 2008) relied on physically chopping up long video files into small file chunks. In order to retrieve the chunks for the web server, the player client simply needed to download files in a logical sequence: 00001.vid, 00002.vid, 00003.vid, etc.

As I’ve explained in this and previous posts, Smooth Streaming uses a more sophisticated file format and server design. The videos are no longer split up into thousands of file chunks, but are instead “virtually” split up into fragments (typically 1 fragment per video GOP) and stored within a single contiguous MP4 file. This implies two significant changes in server and client design too:

1. The server must be able to translate URL requests into exact byte range offsets within the MP4 file, and
2. The client can request chunks in a more developer-friendly manner, such as by timecode instead of by index number

The first thing a Silverlight client requests from the Smooth Streaming server is the *.ismc client manifest. The manifest tells it which codecs were used  to compress the content (so that the Silverlight runtime can initialize the correct decoder and build the playback pipeline), which bitrates and resolutions are available, and a list of all the available chunks and either their start times or durations.

With IIS7 Smooth Streaming, a client is expected to request fragments in the form of RESTful URLs:

http://video.foo.com/NBA.ism/QualityLevels(400000)/Fragments(video=610275114)

http://video.foo.com/NBA.ism/QualityLevels(64000)/Fragments(audio=631931065)

The values passed in the URL represent encoded bitrate (i.e. 400000) and the fragment start offset (i.e. 610275114) expressed in an agreed-upon time unit (usually 100 ns). These values are known from the client manifest.

Upon receiving a request like this, the IIS7 Smooth Streaming component looks up the quality level (bitrate) in the corresponding *.ism server manifest and maps it to a physical *.ismv or *.isma file on disk. It then goes and reads the appropriate MP4 file, and based on its ‘tfra’ index box figures out which fragment box (‘moof’ + ‘mdat’) corresponds to the requested start time offset. It then extracts the said fragment box and sends it over the wire to the client as a standalone file. This is a particularly important part of the overall design because the sent fragment/file can now be automatically cached further down the network, potentially saving the origin server from sending the same fragment/file again to another client requesting the same RESTful URL.

As you can see, requesting chunks of video/audio from the server is easy. But what about dynamic bitrate switching that makes adaptive streaming so effective? This part of the Smooth Streaming experience is implemented entirely in client-side Silverlight application code – the server plays no part in the bitrate switching process. The client-side code looks at chunk download times, buffer fullness, rendered frame rates, and other factors – and based on them decides when to request higher or lower bitrates from the server. Remember, if during the encoding process we ensure that all bitrates of the same source are perfectly frame aligned (same length GOPs, no dropped frames), then switching between bitrates is completely seamless – and Smooth.