Installing process of DotNetNuke (Dnn.Platform-8.0.2) - installation

Downloaded source package of DotnetNuke and I am new in dotnetNuke. Can anyone help me to clarify the process of installing DotnetNuke.
I am following this Install DNN

I've got a tutorial on installing DNN8 found here.
You can also follow this text tutorial
Setting up your development environment can vary based on what your
end goal is. If you are doing module development for your own use, and
within your own DNN environments, you can ignore a few of the settings
below. If you are doing module development with the idea that you
might turn around and give the modules away, or sell them, then you
will likely want to follow the guidelines set forth below to support
the widest array of DNN installation environments.
I recommend that each developer have their own local development
environment, with a local IIS website running DotNetNuke, and a SQL
Server 2008/2012 (not express, though you can use it) database for the
website. Having an individual development environment makes group
module development far easier than if you share
environments/databases.
Choosing a DotNetNuke Version Choosing a version of DotNetNuke is
important when you start your development for couple of reasons. For
modules that you are developing for yourself, you need to ask, what is
the minimum version of DotNetNuke that you have in production. Are you
running DNN 5.6.1? Are you running 6.2.6, 7.0.0, 7.0.6? Based on the
answer you can determine what version of DNN you should setup as your
development environment. You shouldn't be developing on a newer
version of DNN than what you have running in production. As with
everything there are ways around this, but I am not going to go into
the details on that in this tutorial.
As a developer working to create modules and release those, you might
have production sites that are running on the latest and greatest
version of DNN, but what about your customers? Or your potential
customers? You have to ask yourself, do you want to provide support
for really old versions of DotNetNuke? From a development perspective
you will probably say no, but from a business perspective, you might
say yes, and here’s why. Not everyone upgrades DotNetNuke websites as
they should, and often times you will find that some people never
upgrade. While I don’t advise taking that approach to managing a
DotNetNuke website, it is a fact of life that people don’t always
upgrade and there are thousands of people, if not tens of thousands,
that have sites that aren’t running on the latest version of DNN. You
should take that into account when you are doing your module
development, if you compile your module against an older version of
DNN then your module should run on newer versions of as well, for
example. If you compile your module against DotNetNuke 6.2.6 it will
likely run on every version of DNN released since then. Though there
are extended cases where this won’t always work, DNN strives to
maintain backwards compatibility, this isn't always possible.
You might also want to use features that are only available starting
with a specific version of DotNetNuke, such as the workflow
functionality found starting in DNN 5.1, in that case you may choose
not to support older versions of the platform out of necessity. This
will minimize the market in which you can sell your modules, but also
can make for less support and an easier development cycle due to the
features that DNN provides.
Choosing a Package Now here’s one that may baffle you a bit. I’m going
to recommend that you use the INSTALL package for whatever version of
DotNetNuke that you download. What? The INSTALL package? What about
the SOURCE package? Well you can use the source, but you don’t need
it. The module development that I’m setting you up for doesn't require
the DNN source, and using the INSTALL package makes your development
environment cleaner. We aren't going to be opening the DotNetNuke
project when we do our module development, so why have the files
sitting around for nothing? Also, if you've ever tried to use the
SOURCE package for anything, you'll know it isn't easy.
The steps for setting up your development environment will apply to
both the Community and Professional editions of DotNetNuke.
Installation Configuration Once you have the version selection out of
the way you can go through the installation process. While I’m not
going to walk you through the minutest of details of each step of
installing DotNetNuke in this post, I will at least try to point you
in the right direction for each step.
Download the INSTALL package of the version of DotNetNuke you want to
use in your development environment.
Extract the files in the INSTALL package to a location of your
choosing, this location is where you will point IIS (the web server)
when we can configure the website. In my environment I typically use
c:\websites\dnndev.me\ (One item of note: you may need to right click
on the ZIP file and choose Properties before extracting, on the
properties window if you have an UNBLOCK option, click that. Some
versions of Windows have started blocking files within the DotNetNuke
ZIP files, which will cause you problems later during the actual
install.)
Setup IIS IIS is the web server that comes with Windows computers. DNN
7 requires IIS 7 or later (7,7.5,8.0), so you will need at least
Windows Vista, Windows 7, Windows 8, or Windows Server 2008 R2,
Windows Server 2012.
In IIS you should create a new website (Note: If you use an existing
website in IIS be sure to add the HOST binding for DNNDEV.ME), and
point to the folder where you extracted the INSTALL package.
Note: With DotNetNuke 7.0+, .NET Framework 4.0 is required, so be sure
that your application pool is configured to run under 4.0, and not
2.0.
Set File Permissions Setting up the file permissions for your DNN
install is often the step that causes the most trouble. You should
right click on the FOLDER in which you extracted DNN
(c:\websites\dnndev.me) and choose properties. Choose the Security
tab. You need to add permissions for the account in which your
website's application pool is running under. You will want to setup
the permissions to give the account Full or Modify permissions for the
DNNDEV.ME folder. Which account you will use will vary based on your
version of IIS, here’s a simple list of some of the default accounts
based on the version of IIS.
IIS Version Operating System Account IIS 7 Windows Vista, Windows
Server 2008 localmachine\Network Service IIS 7.5 Windows 2008 R2,
Windows 7 IIS AppPool\APPPOOLNAME IIS 8 Windows 2012, Windows 8 IIS
AppPool\APPPOOLNAME
Note: If you are using IIS7.5/8.0 you’ll notice in the above table
that we have APPPOOLNAME in the identity, this is because when you
setup a new website in IIS a new application pool is created. In place
of you should type in the name of the application pool that was
created. You can also bypass this and configure your application pool
to use the Network Service account instead of a dynamic account if you
would like.
Database Configuration In SQL Server you should go through and create
a new database. I always create a database with the same name as the
website, so in this case DNNDEV.ME. Once you have created the
database, create a user that can access that database. I always use
SQL authentication, turn off the enforce password requirements, and
give the user DB Owner and Public access to the DNNDEV.ME database.
Remember the username and password you create here as you will need
them when you walk through the Installation screen for DotNetNuke.
DotNetNuke Installation Screen Populate the installation screen with
the standard DNN information, Host username, password, etc. For the
Database option, choose Custom and configure your database connection,
providing the Server IP/Name, the Database name (dnndev.me). For the
database authentication you'll want to choose the option that allows
you to enter the username/password for the database user that you
created previously.
Now there are two additional options you can configure, normally I
would tell you not to modify these, but from a development environment
perspective I do recommend that you change the objectQualifier
setting. It should be blank by default, you should type in “dnn”
(without quotes), this will prepend “dnn_” to all of the objects that
get created by DNN such as Tables and Stored Procedures. This is not
something I recommend from a production stand point, but if you are
developing modules for sale, then supporting objectQualifier in your
development is recommended. It will save you time down the road if you
have a customer who has an objectQualifier defined on their production
databases.

Follow the following video and it has total two parts one and two part links are givenbelow
Part one
Part two

Related

Can enabling Windows Features be blocked for local admins?

I am working on an installer of a windows application. Due to its dependencies, to make it work, multiple applications need to be installed and also some changes to the windows features (turning on some windows features) are required.
My installer is supposed to be used by companies. In companies, it can be the case that someone has the rights to install software (in program files folder) but is still restricted (for example updates are regulated by the IT department). A typical explanation for this is that someone is a local admin but not necessarily a global admin.
Can it be the case that someone is allowed to install software in the program files folder but restricted in enabling windows features? I need to know this because this would simply mean that my installer should not automatically/automated enable such windows features. It may work on my VM, but it can fail on the customer employee desktop which would cause the installation to fail due to missing rights for one specific action: enabling some windows features.
Can enabling Windows Features be blocked for local admins?
According to this answer there's no group policies to control Windows features. Therefore we could assume that you're safe for now.

Issues updating an MSI through GPO (failures to overwrite/uninstall)

Thank you in advance for considering this question. If a similar question existed, I was unable to find it.
The Issue: Our company packages an application into an MSI. This MSI when installed outside of any GPO properly updates, blocks attempts to downgrade (or move from a higher revision to a lower revision), and never has trouble uninstalling previous versions of the application regardless of how long ago those versions were created/installed. For example, we can install version 1.2.3 and then install version 2.3.4 and the application will properly install without issue. However, we work with a customer who uses GPO to deploy our application to hundreds of PC's. Each time we have provided an updated version of the application the following has been indicated:
On any machine where a previous version of our application was installed via GPO, no matter what the previous version is, the update successfully installs without issue.
On a machine where the application was manually installed (outside of the GPO), and an attempt to update the application via GPO is made - either the application is installed in addition to the old version, OR there remain registry keys to the previous version of the application and the application cannot open/run correctly. In this case the registry keys must be manually removed, and the install is then attempted again from a clean machine.
What we know is that on any machine where the application was originally installed via GPO - updating the application is no problem. On every machine where the application was not installed with the GPO in the first place, updating via GPO fails with one of the problems presented above.
My question is: Is there a technical issue with how the installation is being handled partially through the GPO and partially outside? Does the GPO need to be responsible for the entire life-cycle of the application? OR is it a reasonable expectation that the application be updated both on machines where the original version was manually (outside the GPO ) installed, and when it was installed initially from within the GPO?
One solution we are aware of is simply having all computers manage the application life-cycle (since we know updates work in that environment already), however this would mean that many computers would need to have the manually installed versions removed by hand - and then properly handle the installation through GPO which is an extensive bit of work.
We would greatly welcome any solutions, references to technical documentation that formally shed light on the proper management or expectations here, or links to information. Our research suggests that it is "best" to manage the entire applications life-cycle inside the GPO - but I have as of yet been unable to determine that it is 100% necessary to do so.
Looking forward to any assistance. If any further technical details are required to help the viability of the question, please don't hesitate to request such details.
If you end up with two versions installed in Control Panel, then all other things being correct, the most likely explanation is that you upgraded a per user install with a per machine install (or vice versa). In the GPO world that's related to assigning it to a user or to the computer, something like that. That's easy to verify by getting a verbose log and checking the FindRelatedProducts actions for an indication that another product was found but in a different context.
When you're in GPO mode all the time, I assume each one (whether it's per user or per machine) is consistent, therefore upgrades always work, but they don't work cross-context.
I believe GPO suppresses the UI in most cases, and the UI (or the UI sequence) is sometimes where per user/per machine is set. That might be something else that would cause it, depending on how the GPO publishes to the computer or the user.

Auto Update Solution for VB6 Application

I am working on a VB6 application which has many executable and an Active X dlls.
And there are to be updated in c;lient machines to lates version once in a while which i am asking the user to update manually.
Can you please suggest me a way using which i can update it automatically from the files that can be available online.
Thanks.
Windows Installer has features supporting Patching and Upgrades. Using those techniques you can create various levels of "upgrade" packages.
Your application would need a separate "update" utility that is spawned when the user approves updating, perhaps in response to a prompt your program raises after checking for new versions.
This updater would check the current version and the remote site's catalog of updates to pick the appropriate package, download it to a temporary location, start Windows Installer to process the package (or packages, sometimes you might need to run several Installer runs), and clean up the temp location. Then you might offer to restrt the updated application or on some occasions need to reboot.
This updater would be a fancy form of the common "installation bootstrapper." As you can tell it needs some "smarts" in order to tell what package or packages to download and install in what sequence, when it needs to request rebooting, etc. This would probably be based on a downloaded "rules script" it obtains as part of selecting a valid update option.
After all, sometimes you can just apply a minor upgrade or patch upgrade, sometimes you need a more complete install or entire reinstall.
If your needs are extremely simple (just an EXE and maybe a few DLLs and OCXs - preferably using reg-free COM) you may not need to go to these lengths. However when you start adding in other considerations like multiple programs, data directory creation and security settings, possibly running a settings file conversion or even database conversion, DCOM, firewall, etc. configuration, database drivers or providers, etc. things get complicated quickly. Too complicated for simple snatch and grab updating.
And admin rights/UAC issues are a factor so you'll probably have to deal with privilege elevation.
None of this is trivial stuff. There are people who do little more than construct and test such deployment systems as their entire job.
If you use soemthing like Inno setup to install the application then an update is simple a matter of running that periodically.
You can either detect there is a new version available by checking a web site/local server, or just prompt to run the update after X days.

Redmine on Windows 8

Trying to install Redmine on Windows 8 on this tutorial. Getting this errors:
Tried Bitnami's installer too, but I already have IIS Web Server and don't need the bundled Apache webserver. The installer doesn't give me to choose it's components. It installs Apache by default. So, Bitnami's Redmine is not for me.
What am I missing?
Is there any other good bug & request tracking software? Please don't Google and advise me to some random results. Advise something that you used and really good as Redmine
Once you get the error above, make sure that new WebSite's AppPool has write access to site's folder on the harddrive to complete the install process.
Then open the website in a browser and the installation will complete.
Set security accordingly after the install completes.
Use WebIssues multi-platform bug & request tracking software that fits all your needs instead of Redmine.
WebIssues is an open source, multi-platform system for issue tracking and team collaboration. It can be used to store, share and track issues with various attributes, comments and file attachments. It is easy to install and use but has many capabilities and is highly customizable.
Main features:
The Desktop Client application can run natively on Windows, Linux
and OS X
The Web Client can be used to access the system using a web browser
The server can be installed on any host with PHP 5.2 or newer and
MySQL, PostgreSQL or SQL Server
Issues can be filtered using public and personal views with
configurable filtering criteria
Email notifications can be sent and the Desktop CLient can
periodically check for new and modified issues meeting various
criteria
Various reports can be printed directly from the Desktop Client or
exported as HTML and PDF documents

Automatically authenticating windows users on an apache/Linux server

If I wanna authenticate windows accounts to AD when a user browses to an apache-running site on a Linux server, here are the usual suspects:
 
List item
mod_ntlm (which I used in a distant past) - last update on 2003
mod_auth_ntlm_winbind - last update on 04/2007
mod_auth_kerb - last update on 12/2008
No luck getting any of those to work with a recent, fully patched, windows 2000 AD server.
Do you have any clues as to a recipe that does work? 
-Peter
-- UPDATE
my current build environment is this:
OS: Ubuntu Lucid
Apache 2.2.14 (from repos)
the auth modules I recompiled from source.
Did you just try to drop binary modules onto an existing apache binary, or did you rebuild Apache and the modules from source on your system?
The last time I did this (admittedly 3+ years ago), I found a combination of Apache+mod_ntlm that worked, but I ended up using a less-than-current version of Apache, in order to match the version of mod_ntlm that I found. My conclusion at the time was that if I wanted current, I was going to have to rebuild Apache and mod_ntlm from source, and I didn't have the time to do that.
Unfortunately, that was two jobs ago, and I don't have access to the configuration details.
LDAP. Active Directory should speak the LDAP protocol well enough (although, I believe Novell's eDirectory sticks to the spec better) that you can use LDAP authentication setups to communicate with it. It'll be a lot easier than fussing around with the Windows-centric NTLM garbage.
See this site for an example:
http://www.jejik.com/articles/2007/06/apache_and_subversion_authentication_with_microsoft_active_directory/
The other, likely costly option, is to invest in an identity manager product. Novell, Sun (now Oracle), and IBM all make one. I suspect that, unless you're designing something for a mid-size corporate project, you won't need these. But, they are an option to consider.

Resources