0

This question has been asked before and I've spent two days chewing through it all, to no avail. I've worked in and around DNN since the very early days (anyone remember the IBuySpy portal from 20 years ago?), and I've migrated more than a dozen sites, all without issue. But in this case, I'm getting the old "object reference not set to..." The EventLog indicates an error in InitializePage but not much more to go on. The logs in the DNN _default folder are for some reason not populating; will check this.

The specifics: DNN 5.03.01 site, has worked fine for a client for years. Needs to be moved to a new server. Different domain name for testing, then we'll redirect the live domain name. Site has a default portal at Portals/0 (no longer used); client's portal is at Portals/1. DB is on same box, MS SQL Server.

What I did: created a Portal Alias in the old, live site to reflect the "test" domain name. Copied all file system content. Duped schema to new DB (same version of MS SQL Server), used Schema Compare to make sure it worked, added all data, used Data Compare to make sure it was all there. Logged into new DB using SMSS; works fine. On the new/test DB, disabled all entries in the WebServers table. Verified new portal alias exists, referencing Portals/1. Verified domain name is live with correct new IP. Set up new site on IIS using that IP, referencing Portals/1. Edited connectionstrings and appsettings entries in Web.config, using the credentials that worked with SMSS. Ran the new site by entering the new/test domain name. I also set the permissions broadly on the DNN folder.

Got: [new domain name]/Default.aspx?error=Object+reference+not+set+to+an+instance+of+an+object.&content=0

So I'm getting to the DNN folder on the new server, but it seems something's not right with PortalSettings (guessing here). Maybe it's going to Portal 0 (the defunct one). This shouldn't happen if I create the new PortalAlias before migrating.

Possible complicating factor: The new server contains another complete instance of DNN which handles the live version (a copy) of the Portals/0 portal on the old machine.

Anybody have any thoughts? Something I overlooked? How can I make absolutely certain I'm hitting the database?

Brackett
  • 1
  • 1

1 Answers1

0

In the older versions of DNN there was a PortalSetting value for DefaultPortalAlias. If that was set to something different it is possible you could see similar behavior.

Also, that version of DNN does not log entries to the /portals/_default/logs directory

Mitchel Sellers
  • 62,228
  • 14
  • 110
  • 173
  • Mitch, thanks for responding. No "DefaultPortalAlias" setting in PortalSettings table. Version confirmed as 5.3.1 and working site does log to to _default/Logs, as this snippet shows: AssemblyVersion5.3.1 – Brackett Jan 01 '20 at 18:52
  • I will try running the old code on the old server with the new database on the new server and vice versa to see if the problem can be isolated to the DB. Thx again for looking at this. – Brackett Jan 01 '20 at 18:56
  • For what it's worth, this problem remains unresolved. The Default.aspx file is being reached on the new/test server, but the "object reference..." error persists. Database access is working. The problem has got to be a setting somewhere in the database. It certainly is frustrating to not be able to copy code and database verbatim from one server to another and not have it work. But even following the recommended tweaks (PortalAlias and WebSettings table changes), this is so far a no-go. – Brackett Jan 03 '20 at 20:33