The primary reason for using AS was the integration of Active Forums (AF). Active Forums in my estimation is the best forum module for DotNetNuke (DNN). It is robust and feature rich and is far easier to set-up than any other. The user-interface (UI) is more intuitive than that of DNN’s core module and well worth the investment. I have used AF for many years with great success.

The other main reason was we needed to tie it into a blog/article module. AS had hooks for doing so with Ventrian’s News Articles module. And while I’m covering this, with News Article v7.69 , Scott McCulloch (developer) includes an option for Active Social journal integration. Sweet! <digression>And if you haven’t used modules from Ventrian yet, I have a question…What the hell is wrong with you? Ventrian offers the best module subscription on the planet, period. </digression>

First, setup was relatively easy armed with the products documentation and a wealth of knowledge at Active Modules knowledge base and forums. The AS package includes two modules,  Active Social and Active Forums. The AS module once installed and placed on a page has 3 different set-up options.

The Simple install creates 4 pages that host modules for:

• Forums – Contains the Active Forums module, which has your discussion forums and your Active Social group forums.
• Groups – A single page contains the Listing of all the Groups and displays individual groups when selected.
• Members – This page will show the member list and the profile of a chosen member.
• Inbox – Contains the private messaging interface.

The Standard install contains 9 pages and has some definite SEO advantages, this was the configuration that we choose. Those pages are:

• Forums – Same as Simple
• Group Directory – Contains the list of all the groups in the network.
• Group Details – Default view of a group profile. Only visible once a group has been created.
• Members – Searchable listing of all members of the network.
• Profile – This is the page used to display a member’s profile.
• Inbox – Same as Basic Configuration.
• Social Summary – The Social Stream. This page will show you updates and activity for members and groups on the site. It can be filtered to show specific types of information or certain user types.
• Login – Create a separate page containing only the active social login. This will be used for verified registration or other non-standard logins.
• Sign-Up – A page containing the Active Social Sign-Up wizard. Set this page as the “User Page” in the site settings. It will automatically redirect users to their profile.

Lastly there is the Expert Option, which is according to the user manual is not for the faint of heart and in fact isn’t really covered.

The next step is to configure the modules on the pages and set the functionality your looking for. This is probably a good place to stop and resign myself that there will be a part two of this blog.

Comments welcome…

WebMatrix was developed to be easy and focus on getting results for your website. It has integrated the code editor, database editor, web server manager, all while focusing on SEO. And as your needs grow, you can seamlessly move to Visual Studio.

There are two ways to get started using WebMatrix once you have it installed (download here). You can start with a your own project from scratch or start with one of the web popular Open Source web applications such as DotNetNuke, Umbraco, WordPress and Joomla!.

After you’ve begun working, because WebMatrix integrates with IIS Developer Express and is tightly linked with the Web server components that your site runs on, you can directly monitor real-time Web requests and responses to track down problems right at the source. You can even resolve the little peeves like images that are missing.

SEO tools, much like those available in IIS 7.5 , make optimizing your web application easy and will even take you to your weak spots with suggested solutions.

WebMatrix is the easiest way to learn standards-based Web development and makes it simple to build and publish Web sites on the internet. Start with HTML, CSS and JavaScript and then seamlessly connect to a database or add in dynamic server code using the new ‘Razor’ syntax for ASP.NET Web pages. Your code is easy to read, simple to learn, short to write and works with any text editor. Use built-in helper functions to connect to a database, display a Twitter feed, or embed a video. And with a seamless path to ASP.NET MVC it is now easier than ever to create powerful ASP.NET Web applications.

I’ll provide some feedback as soon as I’ve had the time to fully “kick the tires.” Stay tuned.

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

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.

IIS Manager 7.5

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

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.

Web Site Details

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

Create Website Directory

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.

AppPool View

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.

Securing Resources for your Process Identity

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.

Times change however, and DotNetNuke Corporation is adapting to these changes. For instance the Issue Tracking has been reworked, and the new “Just like Clockwork” release dates. The later replacing the “When it’s Ready” policy. I was never a big fan of this policy but I do understand that a project that relied on a largely volunteer staff, this was a best fit model for DNN. Again, times change.

A few personal observations from someone (me) who has used, developed to and profited from DNN since version 1.5, the iBuySpy fork:

1. I have noticed that the quality of releases since DNN incorporated has risen greatly. There seems to be more attention paid to details and the QA/Testing group appears to have things well in hand.
2. The security of a DNN build has always been handled well, but the newer releases have been outstanding with no critical issues in well over a year. Kudos go to Cathal Connolly for an outstanding effort.

If you haven’t installed and tested this rich development platform, or perhaps you have in the past and lost favor; you need to check-it out. You’ll find a robust community and user-groups world-wide. Give it a shot.

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:

A folder containing a Smooth Streaming media assets

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.

Imagine this – a client connects to your server, clicks on your featured video, watches 5 seconds of it to realize they have no interest in watching further, and move on to the next video.

In those 5 seconds, the server could have sent out 5 minutes worth of the video, and you paid for 5 minutes worth of bandwidth! With the Bit Rate Throtter + media bitrate detection, the server would only end up sending a little over 5 seconds worth, and you would end up paying only for what was used.

Bit Rate Throttling (BRT) is a module plug-in for IIS 7 0r IIS 7.5. It’s an extension of the IIS Media Service. The IIS7 Bit Rate Throttling module was first announced at the National Association of Broadcasters (NAB) show last April as part of the TCO advantage for Silverlight.  Enabling Web masters to throttle the delivery of any file based on the file type. It also has additional functions for digital audio/video files. Throttling can be set at the following levels within Internet Information Services (IIS) Manager: server, site, virtual directory, and file.

BRT contains the following features:

• Fast Start – the ability to send the first part of the media file without rate limiting, to seed the playback buffer in the player and make sure that playback can begin as soon as possible (most players try to pre-buffer a certain amount of the video, often 5 seconds, before starting playback). This also insures that if the connection suffers a hiccup, the playback can continue uninterrupted.
• Disconnect detection - when the client stops watching the video, goes to another page, or closes the video, the BRT detects the connection closure and stops sending the file.
• Built-in support for detecting the playback rate for common media formats, including .asf, .avi, .flv, .m4v, .mov, .mp3, .mp4, .rm, .rmvb, .wma, and .wmv.
• Ability to configure static throttling rates, and media auto-detection rates at any configuration level.

It should also be noted you can configure the BRT module to handle static files as well, such as a large [progressive] .jpg file. So, if you feel you need to trim the bandwidth, Bit Rate Throttling module is a great place to start.

In the next segment I’ll focus on the Smooth Streaming IIS 7+ features and capabilities.

I have a client (to be named later) that had a need to deliver high-quality videos without breaking the budget. By budget I mean in terms of bandwidth, encoding, and preparation. We also host this clients website which was recently moved to a new server running Windows 2008 R2, with IIS 7.5. So in looking for a solution I came upon Silverlight, which is a natural fit with IIS 7.5′s  Media Services and Smooth Streaming.

To make this scenario work, you’ll need Microsoft’s Expression Web 3 or Microsoft’s Expression Studio 3. The Expression Encoder 3 is bundled with those packages with sell from (estimated) $150 to $500 dollars. Both packages offer a wide array of tools that will help in your video encoding as well as many other tasks such as website development and desktop applications.

With Expression Web 3 alone, you be able to code in PHP, HTML/XHTML, CSS, JavaScript, ASP.NET, ASP.NET AJAX, all using standards-based code (yes, I checked), however Expression Encoder is the key. It’s not only easy to navigate and use, but allows you to drop in QuickTime, AVI, MPEG, and other formats into the encoder, and utilize the latest quality and speed improvements to the VC-1 or H.264 codecs, choose a Silverlight template (or make your own), and publish directly to a web server using Expression Encoder Publishing Plug-in. It should be noted that the video can also be published locally and viewed.

Smooth Streaming is the production version of a technology first used by Microsoft to deliver on-demand video of the 2008 Summer Olympics for NBCOlympics.com. By dynamically monitoring both local bandwidth and video rendering performance, Smooth Streaming optimizes playback of content by switching video quality in real-time.

Using Smooth Streaming, visitors with high bandwidth connections and modern computers can experience full HD quality streaming, while others with lower bandwidth or older computers receive the appropriate stream for their capabilities. The result is visitors across the board enjoy a compelling, uninterrupted streaming experience, which ultimately lead to extended visitor stays and increased revenue opportunities.

In my next installment of this topic, I’ll cover the nuts and bolts of Bit Rate Throttling and Smooth Streaming.

Over the past year or so I have become more familiar with and almost comfortable with the LAMP stack (Linux, Apache, MySQL and PHP.) I have been a die-hard Microsoft developer and admit that my strength is in the IIS, MSSQL, and .NET stack. All developer have they’re comfort zone, but I digress. Lets talk Joomla!.

Lets start with the test server. It’s VM running Ubuntu 9.10 with the LAMP stack installed. A freshly downloaded copy of Joomla! 1.5 in place and the installation begins. Here is where some other CMS’s can take a lesson (including BrandX)! The installation was very straight forward and took literally a minute to complete! A few minor configuration settings,a database name, user and presto, your in business.

That was the easy part. Now what to do in this new interface? A new world compared to BrandX! As with any “new” product a learning curve is a certainty, but Joomla! is truly a whole new world. I’ll write back with my finding and I look forward tou your comments.

This probably isn’t anything earth shattering to most, but it certainly beats our old system of taking back-up tapes and DVD off-site every night. That method had too many short-comings to say the least.

Recently, for one of our secure document storage web applications, we started incorporating a data provider that utilizes the S3 API. Setting a search provider for S3 proved to be a bit of a challenge, but so far it has worked out fairly well.

So lets get back to the topic at hand. For the SMB looking for a cost effective way to keep file storage organized and highly available, I’m hard pressed to come up with another viable solution. If you’re the owner of a SMB or work for one, what options have you explored? What method of [off-site] back-up are you using? I’d really like to hear from you…

The major highlights are:

• Fixed issue where banners were not properly rotated according to the specified views/clicks.
• Fixed issue where upgrades could fail if the the user account did not have permission to update objects in some db schemas.
• Fixed issue where list values were visible outside of the Portal where they were created.
• Fixed issue where caching providers were not rendering unicode characters properly.
• Fixed issue with missing Telerik assembly in the source package.
• Fixed issue where Ajax HostSetting was not properly set on upgrade from 4.x installations.
• Fixed issues where upgrades would fail with a unique index violation.
• Fixed issue with the Starter Kit which was missing HTML module files.
• Fixed issue where page templates were not working correctly.
• Fixed default settings for the module and output caching providers.
• Fixed issue which prevented Blog module from working after some upgrades to 5.x.
• Fixed issue when creating a new module in the Module Definition Wizard if the .ascx extension was not specified.
• Fixed issue where localization was not working if the application virtual directory name was also part of the module name.
• Fixed issue where the FriendlyName for Schedule Items was not being saved.
• Fixed issue where GetUserCountByPortal was making excessive database calls instead of using cached values.
• Added binding redirect setting in web.config to prevent versioning issues with Telerik assembly.

Providers:

• FileModuleCachingProvider 05.02.01
• MemoryModuleCachingProvider 05.02.01
• SchedulingProvider 05.02.01