Trying to migrate a Drupal site from a Unix (Ubuntu) server to Windows. New server has Windows Server 2012 R2, IIS 8.5, PHP 5.6.0, Mysql 5.5.42, all recently installed on a newly-created VM.
I went for the home run and zipped up the codebase and dumped the contents of MySQL from the original server and moved it to the Windows server. I created the database with the same root password and everything, and importing it seemed to work fine. Unzipping the codebase also seems to have worked. Although clean URLs seem to not be working, I can still navigate the site with the ?q=[pagename] query string.
However, not everything has gone smoothly. If anyone can help with either of these issues, I'd be grateful.
1) I cannot log into the website, and there seems to be no indication why. We have an authentication setup with an AD backend in addition to the Drupal db, using the "LDAP for Drupal" module. Our employees are in AD, and the site authenticates against it, propagating roles, permissions, personal data, etc. from AD. Non-employees can also log in, and they authenticate against Drupal. The LDAP Module is in "mixed mode," which says,"Drupal authentication is tried first. On failure, LDAP authentication is performed." Using my account, the user 1 account, and a test user account, and nothing lets me in. When I attempt it, it just comes back to the same page. Neither though does it produce an error onscreen, or in any log I can find either in the Watchdog table or Windows (not too strong on how IIS does logging). I created a new user on the new server, and went into the database to activate him and give him a role, but I still can't log in with him, either. I suspect there might be an issue with the hash for passwords, but am really pretty clueless at this point.
2) Some extra files like .js and .css are not being incorporated into the page template. When I compare the source codes of the same pages on the new and old servers, I see a lot less CSS and .js files. When I look at the page through web developer tools, I can see class and style definitions are definitely missing. And while there is some jquery code and it seems to be functional, neither is it being called the same way as the original site that I can tell. I do have CSS and JS script aggregation turned on, so everything is in a small number of files with hashed names, but something is not working there, either. Or at least the system is not creating new aggregations.
3) The clean URL issue mentioned above. I've seen mention of some other Windows things to be installed for IIS to handle the pathnames correctly, but if anyone can give me hard info there, I need it.
So I'm stuck with a skeletal site right now. Any clues?
Comments
Short URLs
Can you turn up the logging in PHP and IIS to see what's going on with the authentication?
Regarding issue number 3) this could be the cause of others if the files are not being served up correctly. Other thing to check is that the output caching is off in IIS.
Below are the 3 rewrite rules used in our IIS 8.5 server (In the
section of web.config file in website root):-
There are plenty of other rules you can add for hardening the site, but these are the basic ones to ensure the clean paths work. Make sure you don't have any others conflicting.
Hope this helps you take a step forward!
Thanks for posting.
Thanks for posting. Unfortunately, what you posted is Greek to me. How do I "turn up" the logging? And adding those rules to web.config caused either errors or the site became unresponsive. Where exactly would they go if the current file is like this?
<?xml version="1.0" encoding="UTF-8"?><configuration>
<system.webServer>
<defaultDocument>
<files>
<clear />
<add value="index.php" />
<add value="index.html" />
<add value="Default.htm" />
<add value="Default.asp" />
<add value="index.htm" />
<add value="iisstart.htm" />
<add value="default.aspx" />
</files>
</defaultDocument>
</system.webServer>
</configuration>
I have verified that the new server can connect to our AD and query data. So the login mystery continues.
OK, so your web.config file
OK, so your web.config file could look like this with the rules added before the default document section (also removed all but index.php)
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<rewrite>
<rules>
<rule name="Protect files and directories from prying eyes" stopProcessing="true">
<match url=".(engine|inc|info|install|make|module|profile|test|po|sh|.sql|theme|tpl(.php)?|xtmpl)$|^(..|Entries.|Repository|Root|Tag|Template)$" />
<conditions logicalGrouping="MatchAll" trackAllCaptures="false" />
<action type="CustomResponse" statusCode="403" subStatusCode="0" statusReason="Forbidden" statusDescription="Access is forbidden." />
</rule>
<rule name="Force simple error message for requests for non-existent favicon.ico" stopProcessing="true">
<match url="favicon.ico" />
<conditions logicalGrouping="MatchAll" trackAllCaptures="false">
<add input="{URL}" pattern="/favicon.ico" negate="true" />
</conditions>
<action type="CustomResponse" statusCode="404" subStatusCode="1" statusReason="File Not Found" statusDescription="The requested file favicon.ico was not found" />
</rule>
<rule name="Short URLs" stopProcessing="false">
<match url="^(.)$" ignoreCase="false" />
<conditions logicalGrouping="MatchAll" trackAllCaptures="false">
<add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true" />
<add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true" />
<add input="{URL}" pattern="^/favicon.ico$" ignoreCase="false" negate="true" />
</conditions>
<action type="Rewrite" url="index.php?q={R:1}" appendQueryString="true" />
</rule>
</rules>
</rewrite>
<defaultDocument>
<files>
<clear />
<add value="index.php" />
</files>
</defaultDocument>
</system.webServer>
</configuration>
Regarding the other issues; I would first disable all contributed modules and get the admin user logging on to the site and then flush all the caches and then try enabling contributed modules one by one (leaving all the LDAP modules until last).
The PHP logging levels are set in php.ini, probably in C:\Program Files (x86)\PHP\v5.6 or your IIS Express folder: C:\Program Files (x86)\IIS Express\PHP\v5.6 Open the "PHP Manager" icon in IIS Admin and this will show you where the PHP.ini file is located for that site. The setting you're looking for is documented along with the other debugging settings: http://php.net/manual/en/errorfunc.configuration.php
Well I was fixing to download
Well I was fixing to download and install a fresh copy of Drupal and see if maybe that would fix things, even though it would involve a lot of reproduction of labor. But I started off by reading the install guide first, and at one point in taling about clean URLs it discusses the .htaccess file. I put some gabarge at the beginning of the file and all of a sudden my site's CSS started being implemented so it looks normal. I took the garbage out and it still works. No idea what is going on there. But #2 I guess is solved.
I have disabled all
I have disabled all contributed modules (specifically the ones that have a database entry with the filename starting "sites/all/modules", which I think is the indicator) and added the web.config file as shown above. Using ?q=[path] still works, although it doesn't redirect you to the regular path, if that's what it's supposed to do. I'm not sure what is needed for the server to handle this type of URL.
Also, cannot quite figure out what's going on when I log in. Looking at the watchdog table, I see when I log in with a user that should be authenticating against local DB, and it has a message about starting a user session, but then there is a message saying the user should have authenticated against LDAP and it closes the session immediately, I think.
What's more disturbing is when I log in as user 1, after confirming I'm using the right password, it blocks me. Watchdog has a user entry type saying,"Session opened for %name" but then the next entry is an "access denied" type with the message "user/1."
But I get the same thing when I create a new user account and try to log in (setting user.status to '1'). It shows access and login timestamps, but watchdog shows a session being opened yet access is denied.
I'm not familiar enough with the very low levels of how Drupal login functions work, so I'm lost here. Could it be the password hash is not working the same between the two servers? But if that were the case, I think I would be able to log in with a newly created account.
Default Theme and Core Codebase?
Have you set the default theme to Garland? It could be some custom code in your theme that's hooking into the login function.
Maybe also check your core Drupal code has not been modified (take a backup of your web folder, then extract the relevant version of Drupal from the original archive file over the top of your existing codebase. This should overwrite any modified files, but leave your settings.php file alone.
The code was clean from
The code was clean from whatever the recent update was, 7.37 or .38. I've set the theme to Garland (using the SQL method here: https://www.drupal.org/node/200774). Still can't get anything working. Logins fail,
Unless anyone has an idea of what else to look at I'm going to try a fresh install.
Fresh install still doesn't allow for logins
I cleaned house and started from scratch. Dropped the database, removed the codebase, and downloaded a brand new zip file. I went painstakingly step-by-step through Drupal's installation guide. I set the permissions, created the settings.php file, updated the web.config file, ran install.php, fixed the error on permissions that popped up, and everything else. I have a nice, shiny, new website with nothing in it. However, the same problem persists, which is that I cannot log into it. I have the user #1 password saved in a text file, which I used to both set it during creation and now that I'm trying to log in. I created a new user and while that seems to have worked, changing the status in the Users table to 1 and copying the hash from the user #1 account also does not let me log in. I tried requesting a new password but email is not set up on the server yet.
But the takeaway is that while there might have been other problems with copying my current site over, I'm still seeing the same problem here, where I cannot log into the site. The watchdog table has the same results, where it records when I log in, but the only message is "Session opened for %name." The Users table does show a timestamp for the login, but the Sessions table does not show any sessions being created. I don't see anything pertinent in the IIS server logs, either.
Does anyone have an idea what would be preventing logins from even the most basic installation? It must be Windows preventing some sort of session creation or other low-level communication, right?
I got it working on IIS 7.5
I'm not sure how much help this will be, but...
I got it working on IIS 7.5 on SQL Server and we ran multiple production sites on it for a couple years (one is still there).
We do have a new Director, so have migrated most things to Linux in 2015.
I had some minor issues with using MSFT SQL Server and had to patch the file =
[site name] \includes\database\sqlsrv\query.inc for the install to work correctly.
I did have an issue with some user IDs being case sensitive and others it wasn't; make sure you have the right case for the user id (you probably do because you see a login). Case was probably related to the Collation of SQL Server, not Drupal - rather than investigate boss said to make all the UIDs all lower case :-)
As a next step you might explore the differences between IIS 7.5 and IIS 8.5.
IF I were debugging this I would do a clean install (again) to a NEW site and leave out everything related to LDAP. Leave this as a basic site (on a new URL) and make sure your authentication works.
We (not me) did put active directory auth into our new site and it works, but it took a while getting the right ports open and fine tuning the authentication between our (new Linux) cloud provider and internal AD people. I believe we had to get a cert or private key or something from the AD group here to get it to work - I'm sorry that I'm fuzzy on the details, I was updated along the way but didn't do the work.
Hang in there, it can be done and the experience for me was better than DotNetNuke overall (but your mileage may vary)
Also check the PHP version that you're running within IIS 8.5, it's a long shot but could be a factor. And make sure you're running it the right way (managed or unmanaged).
-Chris C.
Taking a new tack
Installing from a new download of 7.38 from Drupal was doing nothing. Something gets in the way of actually logging in. As I noted above, the site would come up, but no matter what page I would go to it would say,"Permission denied.". Logging in as user 1 would be denied. I could create a new account and activate it in the database but login would be denied. Nothing to do with LDAP or AD, it just refused to start a session (I think).
Then I found MS's Drupal page https://www.microsoft.com/web/drupal. It has links to 2 packages that promise to install Drupal. The Drupal Commerce link is inexplicably broken, but the Acquia package works. After stepping through that install process, I had a working Drupal website. I'm not sure what it did, but I assume it installed some packages that IIS was missing and I could now log in, at least.
Acquia currently gives you a 7.35 site, and I've been trying to migrate the existing codebase and database, but it fails. Something breaks, and if I'm not getting a whitescreen, I am getting a page with warnings and errors saying it cannot find a particular file, which might be included or referenced in a block, or a template file or something. For example:
Warning: include(): Failed opening 'C:\inetpub\wwwroot/sites/all/themes/coolblue/block.tpl.php' for inclusion (include_path='.;C:\php\pear') in theme_render_template() (line 1525 of C:\inetpub\wwwroot\includes\theme.inc).
The path is correct, but I don't know if the switch between \ and / causes problems. In one of my trials, I was able to install my coolblue theme and it worked OK. I might have to see if there is something missing from the PATH variable that might help.
However, after that, I was able to do a clean install of Drupal 7.38 and it worked. I'm trying a few different ways of copying over the site from the Linux box but so far nothing is working. I might try the "Backup and Migrate" module and see what that does for me. But I don't have high hopes there. Maybe if I can get Apache installed on Windows I might fare better.
If I could at least figure out which database tables to copy that contain the content of the site it would be most helpful. There are several tables with references to the web pages (node, field_data_*, field_revision_*, probably several others) but that would save a huge amount of time.