Host Administration

1. Manage Host Account:
1. The first thing you want to do is create another SuperUser account and then retire the default host account. It's a prudent security measure in any software installation to retire default administrative accounts to thwart dubious hacking efforts. At a minimum, you'll want to change the password for the default host account, although you can delete it entirely.
2. Configuring Your Host
1. Site Configuration
2. Host Details

   Host Details Settings

   Setting	Description
   Host Portal	This drop-down selection identifies which portal in the installation is to be considered the default. The default portal attributes are used where no other portal context can be determined. For example, when an invalid URL is used to reach the installation, the request is answered on the first alias of the specified Host Portal.
   Host Title	This value is used to populate the text for the [HOSTNAME] skin token. Prior to version 3.0, you could see the [HOSTNAME] skin token in action on the bottom of the default skin. It was often imposed by the host as a means of injecting a "powered by" link into each portal's skin.
   Host URL	Specifies the link target for the [HOSTNAME] skin token. (This is not the same as an alias for the default portal.)
   Host Email	Most e-mail in DotNetNuke is sent to or from the individual Portal Administrators. However, there are a few specific cases where the Host e-mail address is used (for example, an SMTP configuration test, a [HELP] skin token, and so on).

3. Appearance

   Appearance Settings

   Option	Description
   Show Copyright Credits	Inserts the DotNetNuke version number into the browser's title bar and populates the [DOTNETNUKE] skin object. In the default skin, this is displayed as a small thin bar across the bottom of the page that shows the DotNetNuke copyright (see the bottom of Figure 5-3).
   Use Custom Error Messages	Specifies whether DotNetNuke or ASP.NET will intercept module errors. If this option is selected, DotNetNuke displays only basic friendly messages to non-Admin users. If the user is an Admin (or Host) user, full error information is made available. Figures 5-4 and 5-5 illustrate the difference between the same error messages presented to Users and Administrators/SuperUsers, respectively. Detailed information is also retained in the error log.
   Host Skin	If a skin is not specified in the portal Site Settings, this skin is used as the default for each page where a skin is not explicitly specified in Page Settings. The Host Skin, Host Container, Admin Skin, and Admin Container settings work exactly like their counterparts in the Portal Administrators Site Settings. For more detail, see Chapter 4.
   Host Container	If a container is not specified in the portal Site Settings, this container is used as the default for each module where a container is not explicitly specified in Module Settings.
   Admin Skin	If a skin is not specified in the portal Site Settings, this skin is used as the default for Admin pages.
   Admin Container	If a container is not specified in the portal Site Settings, this container is used as the default for modules on every Admin page.
   Upload Skin	Uploading a skin from the Host Settings loads it into the Host's default folder, which makes it available to all portals. This is in contrast to uploading from Site Settings, where it loads into the Portal Root folder. Skins uploaded from Host Settings are located in \Portals\_default\Skins.
   Upload Container	Uploading a container from the Host Settings loads it into the Host's default folder, which makes it available to all portals. This is in contrast to uploading from Site Settings, where it loads into the Portal Root folder. Containers uploaded from Host Settings are located in \Portals\_default\Containers.

4. Payment Settings

   Payment Settings

   Setting	Description
   Hosting Fee	Represents a default monthly charge associated with hosting a portal. This value is displayed on the Host's list of portals and is applied to new portals at the time of their creation. It can also be specified within a portal template, which would override this default value. If subscription renewal is activated, this fee is used for the monthly renewal rate.
   Hosting Currency	Default host currency is used in conjunction with the specified Payment Processor (for example, as a required parameter for PayPal processing). This value is applied to new portals at the time of their creation but can also be overridden within a portal template.
   Hosting Space (MB)	Specifies a default disk space limit for new portals. As with many other portal values, it can be overridden in a portal template. It is an enforced limit that's displayed at the base of the File Manager in the Portal Administrators view. As Host, you can change this value in the Site Settings for a specific portal.
   Demo Period (Days)	If Anonymous Demo Signup is enabled, the Expiry Date for a new portal is set this many days into the future. As Host, you can change this value in the Site Settings for a specific portal.
   Anonymous Demo Signup	This is a legacy feature and its use is highly discouraged. If this option is disabled, only the Host Administrator can create a new portal. If enabled, anonymous users can sign up and immediately log in as Portal Administrator to their own child portal. You have to create your own link somewhere to reach the signup page, but you can copy it from your browser's address bar after clicking Add New Portal on the Portals page. It should have a form like one of the following (depending upon your FriendlyUrls settings): http://soccer.dotnetnuke.com/Default.aspx?tabid=17&ctl=Signup&mid=321 http://soccer.dotnetnuke.com/tabid/17/ctl/Signup/mid/321/Default.aspx This page is not illustrated specifically, but it uses the same control as standard portal signup, which is shown later in Figure 5-12. A legacy feature of DotNetNuke, this setting was originally provided to showcase the capability of DotNetNuke to host private portals for potential clients. Although it's still supported in version 4.0, it is not without its share of legacy issues. Demo signup is enabled through-out the installation, not just on the Host Portal, so a clever anonymous user who locates a DotNetNuke site might try the demo portal signup. The Portal Root ensures file separation and the host File Upload Extensions setting protects from unsafe files, but a malicious user who finds your site could use you as an anonymous download location for the duration of the demo period (or until you catch him or her). Further, because the user chooses the child portal name, you could wind up with unpleasantly named folder paths indexed by search engines that you would rather not have. Because demo signup creates the user as Portal Administrator, a valid e-mail address is not even required.

5. Proxy Settings

1. In general, DotNetNuke should not require specific Proxy Settings. However, some modules may address additional ports for which Proxy Settings are required in your environment (for example, RSS, FTP, NNTP, and so on). Standard settings are configurable for the Proxy Server Name, Port, UserID, Password, and Timeout duration.

6. SMTP Server Settings

1. In hosting situations, the web server itself often runs a simple SMTP service for handling outbound e-mail generated by web sites. Although this setup initiates outbound e-mail, that mail is often flagged as SPAM by the target domains (especially domains like Hotmail.com, Yahoo.com, and so on). For best results, the SMTP server you specify should be the one in the MX record for your domain. Depending on your SMTP server's configuration, it may be necessary for Portal Administrators' e-mail addresses to be recognized on the server as well.

   If you are testing from a home network via a broadband connection, be aware of your ISP's policies regarding SMTP servers. Generally speaking, most ISPs do not allow the trafficking of e-mail from other SMTP servers on their networks (as a SPAM control measure). You either need to configure DotNetNuke to use the credentials of your ISP account (just as you would in your local e-mail client) or configure a local SMTP server to relay through your ISP and specify that local server in DotNetNuke.

7. Other Advanced Settings

1. Setting	Description
   Control Panel	Select the Control Panel that Portal Administrators will use. Chapter 4 contains a full description of the choices. The capability to select the Control Panel exists largely to promote the concept of creating customized Control Panels for the host. If you created your own Control Panel, what would you make it look like?
   Site Log Storage	Enables you to specify whether site log information is stored in the database or in files. File-based logs are written using the IIS 6 log conventions and are stored in the each portal folder with the following naming convention: / portals//logs/ex.log. The database option is specified by default.
   Site Log Buffer (Items)	This value defines the number of site log entries that are held in memory before storing them. Setting the buffer to 0 turns logging off entirely. Changing the buffer value does not affect the actual I/O cost of logging, but it does change where and when the cost is incurred. For example, if the log buffer is set to 1, every page request in every portal will incur the (slight) overhead of the log I/O, whereas if the log buffer is set to 20, only 1 in 20 requests will incur the overhead, but it will incur the overhead of all 20 I/O requests.
   	If the cache is cleared (whether by the restart of the application, in Host Settings, or by other means), any uncommitted items in the log buffer are lost. Individual buffers are cached for each portal, but this setting applies globally to all of them. Setting this value too high could result in data loss for low traffic sites whose cache might expire (and be lost) before reaching the buffer threshold.
   Site Log History (Days)	DotNetNuke performs site logging on an individual portal level and retains that information for the number of days specified. This value represents the default duration that will be applied to each new portal created. Changing this value has no effect on the configuration of existing portals, although as Host, you can change this value in the Site Settings for a specific portal. Expiration of site log data is contingent upon execution of a scheduled job, which periodically truncates the buffer to the duration specified. The PurgeSiteLog job must be enabled in the Scheduler for this to occur; otherwise the SiteLog table can grow unchecked. Job scheduling is covered later in this chapter.
   Disable Users Online	UsersOnline is a popular functionality in many online portal applications, tracking and displaying the number of users registered on the site, how many users are currently using the site, and so on. However, this functionality imposes unnecessary processing overhead on each page request for sites that don't need it. By checking this option, logic within DotNetNuke that populates UsersOnline tracking tables and cache objects is bypassed for the entire installation. Setting this option is only half the process required to enable or disable UsersOnline. An essential part of UsersOnline is a corresponding scheduled job that performs periodic cleanup on the associated AnonymousUsers and UsersOnline database tables. If this job is enabled without UsersOnline in use, it is an unnecessary drain on system resources. Conversely, if it is not enabled when UsersOnline is in use, these tables grow unchecked. Job scheduling is covered later in this chapter.
   Users Online Time (Minutes)	UsersOnline tracks the presence of users who have been active on the system within this time period. When the scheduled job runs to clear the tracking tables, it uses this time period as a basis for determining which records to clear.
   	UsersOnline does not track or log personal information and is not a mechanism for "spying" on users. It makes temporary note of who is logged in, what page they are currently visiting (no history), and how many anonymous users are currently viewing the site. The data is deleted after this duration has passed.
   Auto-Unlock Accounts After (Minutes)	As a security measure to thwart hacking attempts, DotNetNuke locks out a user account after a series of unsuccessful login attempts. Such an account can be automatically unlocked with a successful authentication after a certain period of time has elapsed. This value is the number of minutes to wait until the account is automatically unlocked. Enter 0 to disable the auto-unlock feature.
   File Upload Extensions	This comma-separated list specifies the file extensions that are permissible through the File Manager. It comes prefilled with a variety of common "safe" file extensions and can be fully customized. The file management utilities within the portal are "intelligent" and reference this allowable file list. For example, a file that is renamed in the File Manager cannot be renamed with an invalid file extension. Likewise, files with invalid file extensions are ignored when an uploaded zip file is unpacked.
   Skin Upload Permission	You can enable Portal Administrators to upload skin and container files by selecting Portal. To restrict them from uploading skin and container files, select Host.
   Module Caching Method	Module instances have a Cache Time setting that can be modified to improve performance in relatively static modules. This setting controls whether module caching is performed on disk or in memory. Memory caching provides the most flexibility and is the highest performance method, but it also consumes the most system resources. When this option is enabled, HTML files are created and stored on the file system in the following format: \Portals\\Cache\TabModule__.htm
   Performance Setting	A variety of cache objects in DotNetNuke provide for increased performance. They do not all have the same duration. They expire based on their specific functionality — for example, User objects expire more often than Portal objects. Changing this setting applies a common multiplier that affects their relative duration (or lifespan). The duration is enforced within DotNetNuke, but it's still subject to external settings that govern the site (such as recycling the ASP.NET worker process). Moderate caching is the default setting. The No Caching option is primarily developer-or support-oriented. Without the benefit of the caching features of ASP.NET, the amount of work performed on each page request renders DotNetNuke slow to run and is not recommended. However, this option can be useful in tracking down a caching-related issue.
   Clear Cache	Enables the Host to manually clear the cache on demand. Generally this is not required; however, as Host, you typically have access to manipulate database tables directly. Table updates applied this way bypass the application and may not be reflected until the cache is updated. You can force an update of cache to reflect your manual changes by clearing it. (Clearing the cache this way also dumps buffered logs, so it should be performed only when necessary.)
   Scheduler Mode	The Timer Method maintains a separate thread to execute scheduled tasks while the worker process is alive. Alternatively, the Request Method triggers periodic execution of tasks as HTTP Requests are made. You can disable the Scheduler by selecting Disabled. The Scheduler is examined in detail later in this chapter.
   Enable Event Log Buffer?	Like the site log, the event log can also be buffered for performance to avoid the overhead associated with logging I/O on every request. If checked, this setting causes event log entries to be buffered into cache and periodically written to the data store. If unchecked, log entries are written immediately. Unlike site logging, event log buffering is governed by a scheduled task (PurgeLogBuffer). If this task is not enabled or if the Scheduler is stopped, this setting has no effect and logging occurs as if this setting were unchecked. Event Logging is covered in more detail later in this chapter.
   Use Friendly Urls	If checked, DotNetNuke invokes the FriendlyUrl Provider. By default, DotNetNuke installs a provider that produces "machine friendly" URLs that enable better indexing by search engines.
   	For developers, the default provider behavior is controlled by a rule file (siteurls.config) located in the web root. The default modules provided with DotNetNuke work well with this provider. However, not every module may work well with any specific implementation of Friendly Urls. It is advisable to ensure that any module you employ works with your FriendlyUrl Provider. For more information on FriendlyUrls, see Chapter 8.
   Help URL	The target URL for administrative help, including the Help button in the Control Panel and the Online Help menu item for administrative functions. If this field is blank, the Control Panel Help button is disabled and the Online Help menu item is not available on administrative functions. By default, DotNetNuke provides context-sensitive online help for all standard modules and administrative features at the following site: http://www.dotnetnuke.com/default.aspx?tabid=787
   Enable Module Online Help	If enabled, an item for Online Help appears in every Module Actions Menu. This requires that a Help URL be configured in the Module Definitions for each module in use, although the developer may have provided this.

   
   
8. 
   
3. Managing Portals as Host
   You can reach the site settings for any portal through the Portals page (Host ð Portals)
   
   
1. Portals
   From the Portals page you can create and maintain portals as well as generate a portal template for import into another DotNetNuke installation.

   Host-Only Site Settings

   Setting	Description
   Expiry Date	When the expiry date for a portal is exceeded, a friendly message is displayed in the place of regular content (see Figure 5-10).
   Hosting Fee	The default for this value is established in the Host Settings. This is primarily a display field that indicates the value appropriate for monthly renewal.
   Disk Space	The default for this value was set in the Host Settings. It limits the amount of disk space available to a Portal Administrator through the File Manager.
   Site Log History	The default for this value was set in the Host Settings. It keeps the site log for this portal truncated to the number of days indicated.
   Premium Modules	Modules can be installed for use by any portal or can be limited to use in specific portals by setting them as "premium." This set of controls identifies which premium modules have been applied to this portal. You learn more about host management of modules later in this chapter.

1. There's also a new control at the bottom of the Site Settings page for maintaining the list of aliases (domain names) for the portal
2. Prior to version 3.0, all portal aliases were maintained in a comma-delimited string, which restricted the number of aliases that could be assigned. Additionally, it made processing based on individual aliases more complex and inefficient. Starting with version 3.0, portal aliases are maintained as a list of separate items. To add an additional portal alias, simply click Add New HTTP Alias and enter it in the text box provided. A portal can answer to an unlimited number of portal aliases.
1. Adding a New Portal
2. Parent Portals and Child Portals
1. Portal Setup is where you put those concepts into practice by specifying either a Parent or Child portal. The only real distinction between a Parent and a Child portal is that a Parent portal alias has a simple URL attributed to it, whereas a Child portal consists of a URL and subdirectory name. An example of a valid Parent portal name is www.dotnetnuke.com. Alternatively, you can specify an IP address instead of a domain name (for example, 209.162.190.188). An example of a valid Child portal name is www.dotnetnuke.com/soccer, and an IP address can be substituted here as well (for example, 209.162.190.188/soccer). A Child portal can be turned into a Parent portal simply by adding a URL to its list of portal aliases.
2. When a new Child portal is created, a physical directory is also created in the root of the web site with the Child portal's name. A page called subhost.aspx is copied into the directory as default.aspx. That's how DotNetNuke can implement addressing of the Child portal by the alias name (for example, www.dotnetnuke.com/soccer) without making modifications to IIS.

3. So why would you create a Child portal instead of a Parent? With a single registered domain name, you can create an infinite number of cname portals (for example, soccer.dotnetnuke.com) as long as your ISP supports a DNS wildcard for your domain. The most popular reason for creating a Child portal is the capability to emulate a single sign-on solution where credentials appear to be shared between portals. This is a common implementation in intranets where departmental portals are involved. Because Child portals exist in the same domain as the Parent portal, they can share access to a domain cookie, which preserves their logged-in status across subportals as long as the username and password are synchronized.

3. Portal Templates

1. This feature enables you to select an existing portal, supply a name and description, and then generate a template that contains all the information necessary to re-create the portal on another installation (see Listing 5-1). Two files are generated in the .template process, and .template .resources. .template is a plain-text file that contains a complete XML representation of the portal, its pages, modules, settings, and file structure. .resources is just a zip file of the portal root that is exported as content (if that option is selected).

2. Portal templates are a powerful capability in DotNetNuke — but this capability is still "raw." This means that we've yet to provide user interface controls to direct how a template file is exported. At this point, template files contain everything including the kitchen sink! If you are creating templates, it would be wise to actually read through the generated file and make sure that there are no options specified that would be inappropriate for where you intend to apply them. As a standard XML file, this is a pretty simple thing to do and removing nodes that you don't want should work fine.

3. Templates provide a lot of power and promise for automatic configuration and for sharing of portal information. However, they should be used with care until they're more fully "cooked."

2. Skins

1. The Portal Administrator and the Host each have their own version of the Skins page. As Host, both are visible and accessible to you, so it is essential that you understand which one you are working with.

2. When using the Admin ð Skins page, you (as Host) always have access to the Upload Skin and Upload Container buttons. These are visible to the Portal Administrator only when the Skin Upload Permission is set to Portal). This enables you to upload skins and containers that are private to the specific portal — those files are uploaded to the Portal Root directory (\Portals\ ).
3. When using the Host ð Skins page, the only difference is the target of the uploaded files. Skins and containers uploaded through the Host ð Skins page are installed in the Default Portal directory (\Portals\_default) and are available to every portal in the installation.
3. Log Viewer
1. As the Host, there are two specific differences in your view of the logs as well as a few additional features.
   
2. First, your view includes exceptions (and any other events that are hidden from the Portal Administrator).
   
3. Second, your view can contain log entries from all portals (if selected as an option). You also have access to some additional functions, including the capability to select and delete specific log entries, clear the entire log, and edit the log configuration.

4. Edit Log Settings

   Setting	Description
   Logging Enabled	Turns logging on for the item. Items can be defined in the log settings without being enabled (for example, the default Scheduler event logging settings).
   Log Type	Select one of the system-defined event types to log or the All category (as appropriate). It is acceptable to define more than one log setting for the same event or for overlapping events.
   Portal	Indicate a specific portal (or All portals) for which this event is to be logged.
   Keep Most Recent	Selecting All preserves all entries in the log. Any other value results in truncation of the log to the maximum number of items specified for the log type selected.
   FileName	Multiple log files can be created. This can be handy for monitoring performance and/or activity related to a given portal or event type.
   Email Notification Enabled	When enabled, the SendLogNotifications scheduled job assembles and sends e-mail according to the Edit Log Settings when it runs.
   Occurrence Threshold	Specifies how often an event must occur to trigger e-mail notification.
   Mail From Address	Sent-from address specified on outgoing e-mail.
   Mail To Address	Sent-to address specified on outgoing e-mail.

Other Host Tools

1. Module Definitions
1. The Module Definitions page serves as the administration area for all of the modules installed in DotNetNuke. This page enables you to edit or delete existing module definitions and to add new modules. DotNetNuke comes with a number of basic modules preinstalled.
2. What Is a Premium Module?

1. A module that has been marked "premium" is not freely available to all Portal Administrators. Non-premium modules automatically show up in the selector on every Portal Administrator's Control Panel, but premium modules require Host configuration on a per-portal basis. The Premium module setting enables you to hide special-purpose modules installed or developed for one client from those installed or developed for another. It also enables you to segment your product offerings, providing extra functionality at a "premium" rate.

3. Editing Module Definitions

1. Each module definition is comprised of three sections: the module description, the module definitions, and the module controls
2. The module description settings hold the basic properties of the module. The Module Name is used in the drop-down list of modules available to Portal Administrators on the Control Panel. The Description is displayed on pages that describe the modules (for example, Module Definitions page). The Version is used by module developers when issuing updates of their modules. The Premium setting determines if a module is available to all portals or only those specifically given access.
3. A module can have any number of definitions. A definition directly matches to a single component of a module. For this reason, most modules usually have only one definition — they only add one component to the page.

4. Some modules may add many components to a page, with each component providing differing functionality but part of a logical group. For example, a blogging module might contain a calendar, a list of blog entries, and a search module. These would be configured as three different definitions, but would still belong under the same Module Name (for example, myblog).

5. Each definition may have a number of a controls associated with it. The controls directly map to ASP.NET user controls and each is marked with a name known as a key, which allows DotNetNuke to determine which control to load at runtime.

6. 
   
4. Installing a New Module
1. There are two methods for installing new modules into your DotNetNuke environment. The first is an automated install. The second is manually adding the module definition.
5. 
   
2. File Manager
1. The File Manager works for SuperUsers in the same way as it does for Portal Administrators, with a couple of minor exceptions.
2. You learned previously that the Host can provide resources to all portals (for example, templates, skins, and so on) by making them available through the Host Root folder (that is, \Portals\_default). Where Admin ð File Manager provides access to each Portal Root, Host ð File Manager provides access to the Host Root
3. There is no additional control for applying permissions, because Host Root permissions are not configurable. Only SuperUsers can add, change, modify, or delete files in the Host Root.
3. Vendors
1. Like the File Manager, the Host Vendor page works for SuperUsers in the same way as it does for Portal Administrators.
2. The only difference between the Host Vendor page and the Portal Administrator Vendor page is the underlying vendor list. You maintain a vendor list separate from the individual portals, which is visible by all of them through banners.
4. SQL

1. The Host SQL page is a handy utility for inquiry or remote maintenance. It provides for the processing of simple queries and returns results in a tabular format. It is also capable of executing compound queries and update queries when you select the Run As Script check box.

5. Schedule

1. Carefully assess the items in the default schedule list, their settings, and enabled/ disabled status to ensure that they meet your specific operating requirements.

2. Schedule Item Details

   Edit Schedule Settings

   Setting	Description
   Full Class Name and Assembly	This entry field should contain the full class name followed by the assembly name (such as "DotNetNuke.Entities.Users .PurgeUsersOnline, DOTNETNUKE"). Assemblies may belong to modules, skin objects, or other components you have installed that leverage the Scheduler's programming interface as long as they inherit from DotNetNuke.Scheduling .SchedulerCllient. Installing a component (or module) may actually create a Scheduler item for you rather than relying on you to create it yourself. Read the instructions carefully for any modules or components that you install.
   Schedule Enabled	Enable or disable the schedule item. If disabled (unchecked), the Scheduler ignores the item when processing.
   Time Lapse	Set the desired frequency for running this item (that is, every x minutes/hours/days).
   Retry Frequency	If the task fails when it runs according to the specified frequency, it is retried according to this setting until the next regularly scheduled start.
   Retain Schedule History	Each time a scheduled item is run, its success/fail status and a number of other useful information items are logged. This value determines the number of log records that are retained in this history. Older items are truncated from the log.
   Run on Event	Enable a job to run on an event rather than on a schedule. The only event currently supported is APPLICATION_START because events triggered on APPLICATION_END are not guaranteed to run in ASP.NET.
   Catch Up Enabled	If the Scheduler is unable to run when the scheduled start time of an item passes, the item is not run. This condition could be caused by any number of things, including a server reboot or recycling of the ASP.NET worker process. This setting indicates whether, at the next scheduled start time, an item should run only once according to the schedule or play "catch up" and run once for each scheduled start that was missed. Under normal circumstances this setting isn't necessary, but it is available for custom schedule items that require it.
   Object Dependencies	When the Scheduler Mode is set to the Timer Method in the Host Settings, it executes as a multithreaded process. This requires some method of protection against possible deadlock conditions for simultaneously running threads.
   	This field provides for the specification of one or more comma-separated string values, which serve as semaphores to avoid deadlock. For example, if one scheduled item performs a select on the Users table and another item performs a massive update on the Users table, you might want to prevent these two items from running at the same time. So both items should have an object dependency on the same string value (for example, "LockUsersTable"). The dependency suppresses the start of any other items until the currently running item has finished.
   Run on Servers	When you're running in a web farm environment, it may be necessary to limit the instances of any given scheduled process. If this comma-delimited field is empty, the scheduled process runs on any server that invokes it. However, if the field is not empty, a server only runs the process if it finds a match on its server name. Using this method a web farm can be configured to prevent multiple web servers from attempting the same database operation at the same time. Redundancy can be preserved by configuring the same processes to run on different web servers on complimentary schedules.

3. Schedule History
4. Schedule Status
5. Configuration
1. The Scheduler has a couple of useful settings that can be manipulated in the application's web.config file.

2. Schedule Provider Configuration Settings

   Setting	Description
   debug	When this is set to "true", a lot of log file entries are generated that help in debugging Scheduler-related development (that is, developing your own Scheduler items). Debugging multithreaded applications is always a challenge. This is one setting that can help you figure out why a task is or isn't getting run.
   maxThreads	Specifies the maximum number of threads to use for the Scheduler (when in Timer Method mode). "-1" is the default, which means "leave it up to the Scheduler to figure out." If you specify a value greater than 0, the Scheduler uses that number as the maximum number of thread pools to use.

   Listing 5-2: Schedule Provider Section of web.config

   
               type="DotNetNuke.Services.Scheduling.DNNScheduling.DNNScheduler,
                     DotNetNuke.DNNScheduler"
               providerPath="~\Providers\SchedulingProviders\DNNScheduler\"
               debug="false"
               maxThreads="-1"/> 

3. Considerations

1. One limitation of the Timer Method mode of the Scheduler is that it cannot run 24/7 without help from an external program, the ASP.NET worker process. This is a constraint of ASP.NET, not of DotNetNuke. The web site's worker process periodically recycles according to settings in IIS or machine.config. Some hosts may have settings that recycle the worker process every 30 minutes (forced), whereas others may have more complicated settings, such as recycling the worker process after 3000 web site hits, or after 20 minutes of inactivity. It is this recycling of the worker process that shuts down the Scheduler until the worker process is started again (that is, by someone hitting the web site, which in turn starts up the worker process, starting up the Scheduler as well).

   This functionality is actually a major benefit to web applications as a whole, in a hosted environment, because it keeps runaway applications from taking down the server. But it isn't without its drawbacks.

   The bottom line is that the Scheduler will run 24/7 in the Timer Method mode as long as someone is visiting your web site frequently enough to keep the worker process active. It is during periods of inactivity that the worker process could possibly shut down. It is for this reason that you should carefully plan the types of tasks you schedule. Make sure that the tasks you schedule are not time critical — that is, don't have to run "every night at midnight" and so on. A more suitable task is one that runs "once per day" or "once every few minutes," and doesn't mind if it's not run during periods of inactivity.

   The Request Method does not have the same dependency on the ASP.NET worker process. However, it is entirely dependent upon the timing of visitors to your web site. During periods of inactivity on your web site, scheduled jobs do not run.

6. Languages
1. Background

1. If the Portal Administrator edits a resource file, it will override all resources loaded from the default resource file. Even if the Host subsequently makes changes to the same set of resource strings, these changes will not be reflected in the portal, which has its own copy of the original resources.

2. Using the Verifier makes managing localized resources much easier, but ultimately it is still up to you to handle localization. If this still seems like too much work, DotNetNuke provides a shortcut. Instead of localizing resources yourself, you can load resource packs that were created by someone else.
2. Globalization
1. Globalizing an application requires more than just having content appear in a specific language. Another aspect of globalizing an application requires that the application understand the time zone of the current user.
2. To solve this problem, DotNetNuke stores all time in Universal Time Coordinated (UTC) format. Each user can associate a TimeZone with his or her profile. This setting is used to localize the time for the current user.
7. Search Admin
1. The Search Admin page enables you to configure certain aspects of the search engine features. It's important to remember that you are configuring the search for the entire installation, not just for any specific portal.

2. Specifying the Maximum and Minimum Word Length settings helps prevent you from indexing unreasonable terms. The internal default values are currently 50 and 4, respectively. If you deselect Include Common Words, the search engine won't bother indexing words that exist in the SearchCommonWords database table. That table has the capability to create common word entries for each locale (for multilanguage customization), although only the English language common words are included by default. Likewise, you can choose to Include Numbers or to ignore them when content is indexed.

3. Clicking the Update button saves your preferences. Clicking Re-Index Content causes the search engine to empty its tables and re-index the full content of all portals in the installation.

4. Keeping It Current

1. When you learned about the Scheduler, you may have noticed a scheduled item for the search engine:

   DotNetNuke.Services.Search.SearchEngineScheduler
   

   If you want your portal's content to be current, it is essential that this job be configured to run periodically. As Portal Administrators add content to their web sites, it is not immediately available through site search. It does not become available until the new content is indexed the next time this job runs or until a SuperUser clicks the button to re-index content.

2. The engine that drives search also drives RSS syndication. Updated content is not reflected in syndication until the next time the search index is run.

5. Background
1. Starting in DotNetNuke 3.0, the search engine is fully integrated into the core application and modules are able to hook into this powerful functionality easily. This means that any third-party module can participate in full site search and/or content syndication, simply by implementing the search API . Currently, the core framework provides a search input module that performs full site search and a default search results page.
8. Lists
1. DotNetNuke includes a common utility that enables you to manage the content of lists (where appropriate) and to augment the lists to customize your installation.

2. The list manager is fairly straightforward, providing an index of the lists it is currently tracking as well as a summary of the entries and the capability to add new entries or edit existing ones.

3. Not all lists are ones you should edit without an understanding of the potential impacts. For example, if you were to remove an entry from the Site Log reports list, it would prevent Portal Administrators from ever running that report on their portal. You might consider this a good thing if it was necessary to remove a report that was adversely affecting performance. However, adding a new item to that list would result in application errors because the Site Log report would not know how to process them.
9. Skins
1. As mentioned earlier in this chapter, the only difference between working with skins from the Admin menu and working with skins from the Host menu is the target location of the upload, which determines availability to other Portal Administrators.
10. 
    

Portal Administration

1. The Control Panel
1. The Control Panel is primarily a palette of shortcuts for frequently used tasks, most of which are accessible from other pages through the Admin menu.
2. The Site Wizard
1. A slick addition to version 3.0 and later versions is the Site Wizard, which is the quickest way to make the most common customizations for those new to managing their own DotNetNuke web site. It walks you through a short conversational process, step by step, with extensive help and the ability to cancel at any time without saving the changes. Standard navigational controls appear on each page of the wizard for Back, Next, Finish, Cancel (without saving changes), and Help.
3. Site Settings
1. You can reach your site settings by clicking the Settings button in the Common Tasks area of the toolbar or by selecting Admin ð Site Settings. The Site Settings page contains expandable and collapsible categories of configuration options.
2. Advanced Settings: Security Settings

1. Portal Registration drives fundamental behavior of your site that should be part of your initial design. Through registration, anonymous site visitors can join (or apply to join) the Registered Users role and be granted access to privileged content or site functionality. Because the Registered Users role requires registration and authorization (either explicit or automatic), these functions combine to provide for different options in the registration process
   

2. Security — Portal Registration Options

   Option	Description
   None	Registration is not an available option to site visitors. The Login button remains visible so that administrative access can be gained; however, the Registration button is hidden. Sites that select this option often change their skin to move the Login button to a less prominent location than where it normally appears on the default skin. This setting is appropriate for sites that do not publish privileged content or that process registration offline.
   Private	Registrants apply for privileged access to the site. Until authorization is explicitly granted, access is limited to that of any anonymous user. This setting is appropriate for sites that require approval of registration requests (for example, a private family web site that invites friends and relatives to apply). An e-mail is sent to the registrant advising him or her of the private nature of the site. An additional e-mail is sent upon authorization (if and when it is performed). It is good practice to explain the process for approval of private registration prominently on your site.
   Public	Registration is automatically (and immediately) authorized without validation of the e-mail address. A welcome e-mail is sent to the registrant. This setting is appropriate for sites that want to track usage but do not require validation of contact information.
   Verified	Registration generates a verification code, which is included in the welcome e-mail sent to the address supplied by the registrant. Authorization is granted when the user supplies the verification code at the time of their first login. This process ensures that all registered users have supplied a valid e-mail address.
4. Security Roles
   
1. The DotNetNuke architecture enables you to control access to your content both at the page level and the module level through the application of user roles. A role can be thought of as a group with a purpose (for example, Newsletter Subscriber, Gallery Administrator, or Team Member).
2. Modules may extend the concept of permissions to include purposes relevant to their specific function, but for planning purposes you should consider that roles address two types of purposes (permissions) in the context of portal administration: View and Edit.
3. Public roles are made available to users via the Membership Services area of their Account Profile page. Roles that are not public typically define privileged access for users or areas of responsibility for maintenance purposes.
5. Pages Management
1. Pages are the building blocks of your DotNetNuke portal. They are the real estate where you deposit content to create an interesting site. You can see them represented in menu items, bread crumbs, and site links.

2. If you have created a page that employs a layout of modules that will be common in your site, it may be useful to begin developing new pages using that same layout. You can specify which page to copy and whether the module content should be the same. If you select Copy Content, the modules on the new page will be shadows of existing modules on the Copy Modules From page. All of the shadow copies are linked so that changes to any one will update every instance on each copied page. This can be particularly helpful for things like links modules used for navigation, banner modules displayed on selected pages, and so on. If you do not select Copy Content, new empty modules are placed on the page in the same layout and with the same permissions as the page specified to copy from.

6. Skins Management
1. The Skins page, which is accessible from the Admin menu, gives you the ability to browse and apply skins and containers to customize the look of your site.
7. File Manager
1. File management is an area that was radically improved in version 3.0 and updated with version 4.0 and the introduction of the ClientAPI. Prior to introduction of the File Manager, all files were maintained in a flat structure in the portal root directory, which could easily become unwieldy. Now files can be managed in subdirectories, and those subdirectories can be protected through role-based permissions.
2. Important Properties of the .NET Framework HttpPostedFileClass dictate the size limits for uploading files. DotNetNuke sets these properties in the default web.config file as follows:
   
   
   

3. Using FTP with File Manager

   The File Manager provides a convenient way to move files through the interface. For bulk operations, however, you may prefer to utilize FTP to transfer files (if permitted by your Host). If files are added to your site through any means other than the file upload interface, you need to click the Synchronize Database and File System button. That command instructs DotNetNuke to iterate through the portal root and resolve for any files and folders that may be added or missing. Your Host may have enabled a scheduled job to perform this synchronization for you on a periodic basis, but if you do it yourself, you'll see those files in your drop-down lists immediately.

4. Note Do not delete files outside of the File Manager. Using the File Manager ensures that database references are updated appropriately throughout the application where file references are made (in other modules, for example).
   
8. Languages

1. Languages and localization features are primarily controlled by the Host account; however, the Portal Administrator has limited control to override localization strings and to define the default language for your portal. These settings are specific to your portal and therefore no mechanism is provided to export or import these changes.

9. Authentication
1. Windows Authentication was officially introduced in version 3.2 (for ASP.NET 1.1) and version 4.0 (for ASP.NET 2.0), increasing DotNetNuke's capability to provide a robust platform for intranets. If your portal is in an intranet environment, Authentication allows you to specify an external authentication source for your users (that is, Open LDAP, ADAM).
10. User Accounts
1. The Portal Administrator is able to manage users from the User Accounts page . Access it by selecting Admin ð User Accounts.
2. In support of the Private Registration option, checking Authorized causes an e-mail to be sent to users that provides them with their login credentials and a welcome message.
11. Managing Security Roles
12. Vendors
1. At some point, you may want to develop partnerships with others in promoting your web site and/or complimentary products and services. DotNetNuke provides a number of built-in features to get you started in developing these relationships.
13. Newsletters

1. Periodically, you'll want to communicate with your users. The Newsletter page provides a convenient way for you to do this by enabling you to send e-mail to users in specified roles. Remember when you set up the Newsletter Subscribers role? Here's where you put that to use.

14. Site Log
1. The Site Log displays text-based reports only
2. Logging occurs at the discretion of the Host, who has a number of options for how it is configured. If the Host chooses to generate text-based log files (like IIS logs), these reports become obsolete because they work only with database logging information (at this time).
15. Recycle Bin

1. The act of deleting a page or module doesn't really delete anything — it merely sets a flag that DotNetNuke understands internally as deleted and ignores it in the general interface. Items that have this flag set can be found in (and restored from) the Recycle Bin.

   Note

   Developers can see this implementation by looking at the database fields Tab.IsDeleted and Modules.IsDeleted.

16. Log Viewer
1. The Log Viewer gives a Portal Administrator the ability to monitor a variety of events and associated details including (but not limited to) exceptions. Out of the box, DotNetNuke is configured to log exceptions only; however, any of the (approximately) 48 defined events can be logged at the discretion of the Host.

Important Concepts of DotNetNuke

1. Parent/Child Portals

1. A child portal has its own discreet membership, modules, and so on — essentially its own portal entirely — within the same domain as a parent. DotNetNuke creates a physical directory and file that enable IIS to recognize the portal's existence. Child portals make sense within a single domain, leveraged to intranets, SSO, and so forth.

   A parent portal has no subdirectory, although it can remain within a domain by using cnames (sales.Domain.com, for example).

2. Pages
1. Pages are a relatively new term in DotNetNuke. Prior to version 3.x, these were called tabs. This change was made to allow for a more user-friendly experience for the novice who may not be a programmer by trade. You can think of a page in the same way you think of a static HTML page. The difference is that the application loads the content based on the parameters passed to it at runtime.
3. Panes
1. Panes are the areas of your skin that hold the various content modules you drop on each page. These enable you to organize your content in a manner that makes the best use of your site's real estate. The number and placement of panes is a function of your skin design.
2. If DNN cannot find a pane — that is, a pane name that matches — it puts the modules in the ContentPane. If a skin is significantly different, the layout changes, but all the functionality is preserved (nothing breaks).
4. Containers
1. Containers enable you to enhance the look of your portal without any design changes to your skin. A container's purpose is to surround the content of a module with some design element, which allows you to bring more attention to the content of the module. You have two options for applying containers to your portal: You can apply a default container to your entire portal and, if desired, set a container for each module. Go ahead and add a module to a page and set up a container for a visual reference.
5. Modules
1. Modules are the meat and potatoes of a DotNetNuke site. They are the components that display relative, easy-to-update content to your visitors.
6. User Roles
1. DotNetNuke offers a fairly robust method for dealing with permissions and controlling the tasks a particular user is allowed to perform. It does this with a roles-based security module, where every page and module in the application is assigned roles that determine what the user is allowed to do within the context of the application. You have the option of setting permissions at several levels within the portal. A user may be allowed access to edit certain modules or be given access to edit the entire page, as you deem necessary. These functions also apply to viewing a module's content or a specific page. Basically, all you need to do is create the necessary security roles and assign the permissions you want that role to perform to the module or page. After you have the roles and permissions defined, you can then place your users in the appropriate role, which will allow or restrict their access based on those permissions. This allows very granular control over the actions of users in your portal.
7. 
   

Study Plan (Updating....)

1. Configure and install DotNetNuke_04.06.02
   
2. Learn important concept of DotNetNuke (2007/10/11~2007/10/12)
1. Status:
2. Conclusion:
3. References:
1. Book: Professional DotNetNuke 4.0: Open Source Web Application Framework for ASP.NET 2.0
2. 
   
4. Learn Management of DotNetNuke
5. Learn Module Development (Write my own module)
6. Learn Skin Development (Design my own skin)
7. Learn architecture of DotNetNuke
   

How to delete a hide tab of DotNetNuke?

Today I encountered a problem.
I have created a hide tab which has no reference anywhere else in the site.
Later the tab I think is out of use and I decide to delete it.
But I can't find somewhere to execute the action.

Here is my solution:

1. Setup a reference to the hide tab. For example set the user tab to refer to the hide tab in Site Settings.
2. Go to the hide tab and get its tab id.
3. Delete the reference to the tab.
4. Go to the tab directly by the tab id.
5. Go to the tab edit page and delete it.

Install DotNetNuke 4.4.0 on Windows XP

ref:http://bplovegcy.blogspot.com/2007/03/install-dotnetnuke-440-on-windows-xp.html

Steps:

1. Precondition: Your box has been installed the VS 2005 and Sql Server 2005
   
2. Download a copy of DotNetNuke 4.4.0 source pack from its government site.
3. Config IIS
   
1. Extract the the source pack:DotNetNuke_4.4.0_Source to C:\DotNetNuke\.
2. Setup a Virtual directory with name DotNetNuke from IIS, which will point to c:\DotNetNuke\WebSite\
3. Set the the DotNetNuke site: execute permissions-> Scripts and Exectutables, Asp.Net version at the ASP.NET Tab -> 2.0.50727
4. Enable the Enable-Default-Document setting on the Documents tab and make sure the the Default.aspx is in the list.
   
4. Configure Sql Server 2005
   
1. Create a new data base named as DotNetNuke
2. Create a new sql server login user: dnn
3. Add the dnn user as the dbowner of DotNetNuke data base
   
4. 
   
5. Configure Web.Config
1. At the root of the site (C:\DotNetNuke\Website), rename the release.config as Web.config
2. Modify the Connection string of web.config file as following:
1. In connectionstring section:
   
   <connectionStrings>
   
   
   <add name="SiteSqlServer" connectionString ="Server=(local);Database=DotNetNuke;uid=dnn;pwd=dnn;" providerName="System.Data.SqlClient " />
   connectionStrings>
2. In appsettings section:
   
   
   
   
   <add key="SiteSqlServer" value="Server=(local);Database=DotNetNuke;uid=dnn;pwd=dnn;" />
6. Set site root access permission
1. First enable the Enable-Simple-File-Sharing setting of XP
   
2. Add the full control permission of ASP.NET user on the site root folder:C:\DotNetNuke\Website and inherit the setting to all its child files and folders.
   
7. Start to install
1. Access the site url:http://localhost/dotnetnuke/
2. You will see the installation successfully message after a few minutes.
   

Exceptions encountered during installation:

1. Error (HTTP 403 Forbidden) :
1. Detail:
1. This error (HTTP 403 Forbidden) means that Internet Explorer was able to connect to the website, but it does not have permission to view the webpage.
   For more information about HTTP errors, see Help.
2. Solution:
1. Make sure the Enable-Default-Document setting is enabled on the Documents tab of IIS web site property page and the the Default.aspx is in the document list.
2. Access to the path 'C:\DotNetNuke\Website\web.config' is denied.
   
1. Detail:
1. DotNetNuke Configuration Error
   Access to the path 'C:\DotNetNuke\Website\web.config' is denied.
   
   DotNetNuke has extensive file upload capabilities for content, modules, and skins. These features require custom security settings so that the application is able to create and remove files in your website.
   
   Using Windows Explorer, browse to the root folder of the website ( C:\DotNetNuke by default ). Right-click the folder and select Sharing and Security from the popup menu ( please note that if you are using Windows XP you may need to Enable Simple File Sharing before these options are displayed ). Select the Security tab. Add the appropriate User Account and set the Permissions.
   
   
   If using Windows 2000 - IIS5
   
   the {Server}\ASPNET User Account must have Read, Write, and Change Control of the virtual root of your website.
   
   
   If using Windows 2003 - IIS6
   
   the NT AUTHORITY\NETWORK SERVICE User Account must have Read, Write, and Change Control of the virtual root of your website.
   
   
2. Solution:
1. Please check the access permission of the root of the site.
2. Especially the Asp.Net user should have full control of the root folder and all its sub folders and files.
   
3. Especially, only select the second to replace all permission of children.

DotNetNuke Books and Resources

Study DotNetNuke!!!

Today I decide to study DotNetNuke code in detail line by line.

I will rewrite DotNetNuke in C# line by line not by code converter.