I tried this on serverfault first, thinking it was a configuration error, but a test (next to last paragraph) leads me to believe it's some sort of programming error on my part
I have two websites ASP Classic - www.company.com and www.companytesting.com.
At this time of year, company.com is pointed to a folder called website2012 and companytesting.com is pointing to a folder called website2013. The contents of those two folders are almost identical, just minor changes for our season change (which I was supposed to do today - lol).
Up until a couple of weeks ago, I was running Windows Server 2003. To update the "live" website, I'd make a copy of the test site folder, and rename it website2013R1, and point the test site there, then point the live site at website2012.
We now have Windows Server 2008 R2 64. (I had someone migrate the websites to the new server for me.)
The companytesting.com site, when I pointed it to website2013R1, worked fine.
The company.com site, when I pointed it to website2013 (which worked just before, for the companytesting.com site) gives an empty page. (i.e. view source = nothing there.) There is nothing in the failed request log when this happens.
I can use the Explore button/link (upper right) in IIS7.5 and see all of the files there. If I use the browse button (either in general or on the index.asp page) I get the blank page again.
One weirdness about how these are set up is that companytesting.com uses a login (which I think is windows authentication - it's simply a single username and password for staff, and to keep the GoogleBots out of it). Obviously, company.com does not. But redirecting the to website2013r1 kept the login in place. (So I'm not absolutely clear whether that's attached to the folder or to the site. Hitting the company.com site after changing the path did not yield a password request.)
The permissions on the folders all seem to be the same, but obviously, I'm missing something.
Why isn't changing the physical path working?
Added to this to the text I posted on ServerFault - I was trying to do a quick fix, so I copied all of the files from Website2013 to Website2012...and got a blank page again. Copying the old 2012 files back into the Website 2012 folder fixed the problem. This makes NO sense to me since A) the website2012 folder is almost identical to the website2012 folder, and B) The website2013 folder ran just swell running under a different domain name. It's obviously something I did programming-wise, but WHAT? Most changes were very minor (e.g. changing the text "2012" to "2013").
As is probably obvious, I'm not knowledgeable about servers. I did OK in 2003, but since it's not my main task and I'm buried right now, I have barely looked at 2008. So I may have really stupid questions when you ask me to check something.
The issue lies in the different ways Win Server 2003 and Win Server 2008 handled the password protected testing site, or at least the way the consultant I hired set it up.
The problem was that the web.config file varied between the website2012 and website2013 folders. Access to the development site was restricted in the web.config file, and contained the line:
<remove users="*" roles="" verbs="" />
Since the live website didn't have a username/password attached to it, it didn't bring up the username password box and simply gave me a blank page.
I dropped the web.config from the "old" website into the website2013 file, and the problem was solved.
(Odd to be answering my own question, but I hate running across unanswered posts when I'm searching for a solution to a problem.)
Related
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?
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
I'm facing an apparently common issue: I can't manage to login in a recently installed Apache Tomcat 8.
The Tomcat installation is part of a large system comprised of a database and other apps and it's not the first time I've installed it just as it isn't the first time I faced this problem. Being so, I did all the steps that helped me fix the problem the other times based on countless pages I found on the web and here on SO about this problem:
Accessed the user XML file and gave all permissions, especially manager-gui, to my created login with no empty spaces between commas
Changes in the XML file were proceeded by closing it in Notepad++ to avoid app locking the file
Changes in the user XML file were preceded by shutting down the service in Windows Services and turning it up again after changes were made
Login and password were set and changed multiple times to be sure it wasn't any kind of mistyped information
The access port in server.xml was changed to more than one different option to be sure there wasn't any port conflict with another app (unlikely since the Windows Server running the app is practically clean)
The read permissions of the user XML file were checked and are in place.
And of course, I reinstalled it at least once.
And maybe more troubleshooting steps I can't remember right now. And none of this worked.
So I'm asking: which other steps could I do to try to access the Tomcat Manager (localhost:port/manager) from a web browser (Chrome/Firefox) from within the same machine it is installed? (no NetBeans involved) I can't think of any other solution.
Well I finally managed to access the manager after appealing to the last resort I had forgot to do: copy and paste of the entire conf folder from a Tomcat which was working to the one having the problem and even so it didn't work by itself, since I still had to change the port from 8080 to 8088 for it to finally work. It seems, therefore, it was a "binary problem": the port wasn't adequate plus differneces in configuration. Comparing the files, I managed to find small differences for example in the web.xml files:
*Current, working*
<mime-mapping>
<extension>woff</extension>
<mime-type>application/x-font-woff</mime-type>
</mime-mapping>
*Previously, not working*
<mime-mapping>
<extension>woff</extension>
<mime-type>font/woff</mime-type>
</mime-mapping>
<mime-mapping>
<extension>woff2</extension>
<mime-type>font/woff2</mime-type>
</mime-mapping>
I can't understand why changes such as this one made any difference, but at least it's working. Thanks for the help.
I had a server running WAMP, that served many phpBB forums. The HD went dead in 2010, but recently i was able to recover the whole data.
I put the old installation dir /wamp/ on same path it was before, run wampmanager.exe, server goes up and the website and the forums work fine as they were like in 2010. However, one of them was successful, and that one specifically don't work normally.
The directory structure is:
/AllSites/Foo/
/AllSites/Bar/
/AllSites/GoodSite/
/AllSites/ is an auto-generated apache index, that shows the forum folders (Foo, Bar, GoodSite).
When i navigate to to localhost/AllSites/GoodSite/, i see the browser requesting from http://old.no-ip.url/AllSites/GoodSite, and not from localhost, until it obviously timeouts.
Naturally, i went to GoodSite's phpBB configuration to check if the old.no-ip.url was being set somewhere. Not there, and not via MySQL search for old.no-ip.url string (phpBB actually only asks for /path/, not domain). So i tried to navigate manually to http://localhost/AllSites/GoodSite/index.php and my surprise, entering like that the site works fine and always stay at localhost.
That made me abandon phpBB as the cause of the issue and focus on Apache (i can even remove index.php from /GoodSite/ and it redirects).
Next thing, i went to .htaccess in /AllSites/ and saw Redirect permanent /AllSites/GoodSite http://old.no-ip.url/AllSites/GoodSite. I removed the line, restarted server, refreshed browser cache, but nothing. It always try to go to the old url when navigating to the GoodSite folder.
So i searched for old.no-ip.url in the whole xamp directory (maybe an alias set somewhere) and subdirectories files', for no result (using Notepad++ "Find in Files" option).
So what can be causing this? The only thing that could be redirecting at server level would be apache or maybe php. But there's no such setting, as the Notepad++ search confirmed. Maybe there is something cached? I ran out of solutions. I even tried deleting the .htaccess files.
A fresh installation, installed via an installer (Softaculous, to save time.)
Data seems to be correctly connected and all in the correct places. But most error messages only contain the word "undefined."
I have a feeling it's a permission problem, but the various solutions for it on forums are varied and only seem to work for a small section of people for each.
I'd rather not do a reinstall as all the old data from previous CRM is now imported.
This is running through a cPanel controlled server BTW, if that helps matters.
Yes, It's permission issues. Please update write permission for the web server user and try to delete " cache/jsLanguage/en_us.js " folder from your account.
If a Suite or Sugar install is installed on a temporary I.P whilst using cPanel, at least in our version of cPanel, it hosts the files in a temporary test folder.
Suite (specifically SugarBean.php) tries to access the folders that would exist on permanent domains. So it calls files that are hosted elsewhere on the server.
Soon as the site was pointed to a real domain, it fixed itself, no extra steps necessary, as the files were hosted in the correct place.
Thanks to the hosting company, they explained that to me. I'm not sure if that's standard procedure to store the files differently for temporary i.p addresses.
make sure you are using correct .htaccess
Go to Admin > Repair and do a "Quick Repair & Rebuild". Execute any changes shown at the bottom of the page.
If that doesn't work, go to Admin > Repair and do "Rebuild .htaccess file" and afterwards, Admin > Repair and do a "Quick Repair & Rebuild" again.
I have an issue with an instance of Windows Server 2008 where Server Manager will not open, nor will powershell or anything else really. I've researched solutions and attempted a dozen or so fixes including replacing the machine.config with a known good in .NET/Framework/etcetc, running System Update readiness to repair corrupt files, DISM, the works. I believe the problem stems from a specific manifest file. Remote event log viewing shows dozens of SideBySide errors pointing to this manifest file claiming invalid XML, and upon closer inspection it looks like the thing is just straight up whitespace. I have a copy of the same manifest from a known good server configuration so I'm thinking of replacing it.
First: is this a dumb idea? Is there something I don't know that's going to blow up in my face?
Second: I can't seem to replace the manifest file. Permissions are against me. Upon closer inspection it seems TrustedInstaller is the only account to have write access and above on that folder, and those permissions are locked from me even though I'm running as Administrator with elevated access. I'm guessing this is to prevent me from shooting myself in the foot, but I neeeeeeeeed this to work. So second question: how do I elevate my permissions to access the manifests folder in C:\Windows\WinSxs\?
Thank you for your time in reading this far. I greatly appreciate your collective knowledge and assistance.
Nevermind, got it. I took ownership of the specific manifest file, opened it in notepad with elevated permissions, replaced the contents with the contents of the known good config, saved it. Voila, it works just fine. Restored SYSTEM permissions afterwards to clean up after myself.