Does anyone have all the steps to getting the dotnetnuke portal working on a remote web server?

I'm able to get the portal to work fine on both a WinXP Pro & Win2K server locally, however all attempts at publishing it to the real web server results in the site not working.

I have made the portalalias changes in the Access database accordingly
- sub question: do I need to use the whole URL? http://localhost/mysite,http://www.mysite.com or will this work: localhost/mysite,www.mysite.com
I am using Access to get started so it's not an SQL issue
I have tried uploading a fresh copy of the portal files and running them from the real web server but no luck. I get an error that it can't find the database. Obviously since the scripts haven't been ran yet.
I have gotten tech support to manipulate the permissions everyway we can think.

What am I missing?

Thank you for your time.

Is your connection string correct?
Check username, password, type of data provider, location, all these things.

You do not need the http:// for the sites.

What exactly are you trying to do, are you just trying to allow DNN to do a new install or are you using data you created locally for content and structure?

The only permissions you need on the root of your dnn on the remote web server as well as the place where the database sits are:
Network Service user account(For windows 2003) - Full control
ASPNET User account(Win XP, Win 2000) - Full control
These permissions will need to trickle down as well.

Hello thecrispy1,

At a very basic level I am trying to get DNN 2.1.1 to work on my remote web server using the Access database. I will upgrade to SQL later. I just want to get the basic portal working on a real web server.

I have tried 2 ways to do this, plus several tweaks to each way.

1) Downloaded & unzipped DNN 2.1.1 on localhost. Played with it for a while, started to create my own skins, fell in love with it, then using FrontPage2003 I published it (all files) to my web server. I asked the admin to grant appropiate permissions, I changed the portalalias in both the .mdb.resources files and now the site says:

---------------------------------
Object reference not set to an instance of an object.
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

Exception Details: System.NullReferenceException: Object reference not set to an instance of an object.

Source Error:

An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.

Stack Trace:


[NullReferenceException: Object reference not set to an instance of an object.]
DotNetNuke.PortalSettings.GetPortalSettings(Int32 TabId, Int32 PortalId) +116
DotNetNuke.PortalSettings..ctor(Int32 tabId, Int32 PortalId) +215
DotNetNuke.Global.Application_BeginRequest(Object sender, EventArgs e) +756
System.Web.SyncEventExecutionStep.System.Web.HttpApplication+IExecutionStep.Execute() +60
System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +87

-------------------------------

2) I took the uninstalled DNN 2.1.1 files and moved them all to a different site on my web server in hopes that I could just run it from there and the auto scripts would do the rest. I got the admin to change the permissions and when I run the /default.aspx page I get:

---------------------------------
DotNetNuke Upgrade Error
The Assembly Version ( [ASSEMBLYVERSION] ) does not match the Database Version ( [DATABASEVERSION] )

ERROR: Could not connect to database.

Could not find file 'D:\myhost\webfolder\www.mysite.com\Providers\DataProviders\AccessDataProvider\DotNetNuke.mdb.resources'.
--------------------------------

I am hoping someone has a list of steps (other than the ones included with DNN) that will help me install the portal on a remote server.

Thanks!

I wrote a bare bones step by step quick guide for SQL, it should not be that different for MS Access.

Thanks for the link.

I can get it to work fine locally. I cannot get it to work on my web server.

There has to be other settings that need changed or something?

You state that VS doesn't copy some files... I am using FrontPage and it copied all the files. Still no go. :(

The second error is because it cannot connect to a database so open web.config and check the connection strings at both places the one for old modules and the one for data providers.

I have not used FrontPage to edit a site before and I don't know how it displays/uploads files, but I suppose it is just like VS so it only shows files that were included in the project/solution and many are not included in the project of the download because they cause an error when recompiling. For example the whole providers folder is not included in the project. So you need to copy it manually to the web server. This could have happened in the second error because it says that it cannot find the file at all and it even gives you the path.

Did you try to follow the instructions step by step at all or just read them? I advise you to follow them and just change from SQL to MS access where appropriate.

In the case of unzipping the files directly in the server this should happen automatically after you create the directory in IIS and point it to your folder, no need to change anything just call the directory you created. Again it will be the in the form IP/directory or machine/directory.

In the case of the site uploaded using FP, to access your site from another computer within your organization you will use the IP of the machine or its name followed by the configured directory http://10.10.0.1/mysite, http://myserver/mysite. These are the names that need to be in the DB Portal Alias field.

I've been getting the same error. I tried running through the step-by-step installation document posted earlier but to no success.

VS uses the FrontPage Server Extensions to publish. They are very similiar in that respect.

However... FrontPage is not as restriciting as VS in that FP will publish ALL the files regardless of what's need in the project.

The reason the 2nd error is giving me the full path to the database file is because the web.config files comes pre-coded for that path. That is the true path... ONCE the database creation scripts are ran.

My main issue with the 2nd site is that the database creation scripts won't fire off. I get the permissions error page when I first visit the site: mysite.com/dotnetnuke/403-3.htm

Upon refreshing I get this error while on the mysite.com/dotnetnuke/upgrade.aspx page:

The Assembly Version ( [ASSEMBLYVERSION] ) does not match the Database Version ( [DATABASEVERSION] )

ERROR: Could not connect to database.

I have followed the instructions step by step locally and remotely. The instructions work great locally... I get errors when I do the same remotely.

I agree that after unzipping the files on my web server I should be able to go to http://www.mysite.com/ and everything should happen automatically.

I am a little confused as to whether or not I have to have a directory named dotnetnuke after my domain or if I can install this directly into my <ROOT>

I want this: http://www.mysite.com/
Not this: http://www.mysite.com/dotnetnuke/

In the case of getting the site to work perfectly locally then publishing it to the remote server... I have changed the names in the Portal db.

Note: I can create a new virtual directory on my localhost then copy & paste the files from the original install, change the PortalAlias in the db and viola' the site comes up just fine.

How is that different from publishing it to a remote web server? Other than the whole confusion around the /dotnetnuke/ folder.

Thanks!

I think that when you copy all files after starting the application as localhost in your machine, since the DB is already there, the scripts see it and do not create anything. The relative info about the localhost/yourlocalsite is still there and you should only need to add the alias for this new location. A comma separated list with no spaces and no http://, but you are doing this in localhost and I am not sure why it cannot connect to the DB if it is already there and web.cofig uses a relative path to obtain the full path to your DB.

On a closer look to the second error I can see that the path has the URL inserted in the path. When you create portals using SQL DNN creates a folder for sites other than the default site and puts a default.aspx there. I wonder if DNN in the case of access creates a folder with the name of your site and then puts the Access DB there. I don't know really cause I have never done this, but you can check and see if such folder exists or even better check if the whole path exists.

So let's start with the easiest solution: unzipping the DNN folder and then starting the application.

After you unzip DNN, just go to IIS click properties of your web (www.mysite.com) and point it to the DNN folder, no need to create a virtual directory. Go to www.mysite.com, DNN should run the scripts and create the DB add it's alias to the field.

In the case that you wanted DNN in a virtual directory (not this case) you would create it and point it to the DNN application. Start it from www.mysite.com/myDirectory and this would also run the scripts, create the DB and add the name plus directory in the alias field.

Note that skins you create locally will not work because files point to a directory rather than the root. to have them work pack them for the File Manager and upload them to your site (see skinning document in Documents Folder)

hooligannes97: "After you unzip DNN, just go to IIS click properties of your web (www.mysite.com) and point it to the DNN folder, no need to create a virtual directory. Go to www.mysite.com, DNN should run the scripts and create the DB add it's alias to the field. "

I can't get into IIS for my remotely hosted web site. I have a limited control panel and it does not allow me to see the IIS properties.

I have played with this a bunch more and the ONLY way I can get the site to install and run the database scripts is to have a virtual directory named /dotnetnuke set-up.

After it's installed in a virtual directory of /dotnetnuke/ I am able to copy & paste it else where, make the PortalAlias change in the Access db and it works.

There has to be something in the original files that says it must be installed in a /dotnetnuke/ folder. I am guessing if I can find that file, change it to http://www.mysite.com/ the auto scripts will work.

Anyone have any thoughts on this?

Thanks!

So what does the panle let you do? Can you set the root? in that case don't create a virtual directory or directory at all, just point to the folder.

Otherwise ask your hoster to create the site and point the root to your folder.

Alternatively extract the file to a folder called something else (meaningful to you) and create a virtual folder with that name too. DNN should work as well. Make sure you delete the previous folder.

I stand corrected. I can name my virtual directory anything I want then run the site and it will work.

So why then won't it auto install on my remote web server like it does locally?

I had a similar issue on my remote host. I was pulling my hair out with the host trying to look at permissions. Eventually, I ran the set up on my local host and added the appropriate portal alias for my remote domian location. I uploaded the access DB to the remote host and everything seemed to work okay.

Not sure why but it worked.

George

George,

Were you able to have: http://www.yoursite.com/ or did it have to be something like: http://www.yoursite.com/virtualdirectory/ ?

I have found a new host that has it up and running for me but they are telling me it only works in a virtual directory and it won't work at the main ROOT.

I want: http://www.mysite.com/
NOT: http://www.mysite.com/dotnetnuke/

Thanks!

I have it running like http://www.mysite.com/home

I haven't tried at the root.


George