Terri, a support specialist at OrcsWeb who guest posts here on my site, and who has the 2nd most popular post here, wrote up a nice little post about creating Active Directory (AD) users in bulk easily via PowerShell. If you’re interested in user management or PowerShell in general, go check it out:
http://terrid.me/creating-ad-users-in-bulk-with-powershell/
Happy admin’ing! 
PS: Terri also has some great posts over at OrcsWeb.
If you’ve recently changed domain names, or made a copy of the site (for testing, development, or any other purpose) then you need to update the domain setting in WordPress. If you don’t, then all links will point back to the old/original domain name and take you away from the new site. You may also (very likely) run into issues trying to sign in to the admin pages of the new site because of domain name mismatching from what WordPress expects.
The *best* way to change the site’s domain name setting is through the WordPress admin pages. If for some reason you can’t do that, then you can also directly edit the MySQL database. Look at the wp_options table and specifically the record(s) for option_name=’siteurl‘ or option_name=’home‘.
If you can’t access the database you can also manually override the domain setting. To do this locate the wp-config.php file which should be in the root of your WordPress site. Open the file in your favorite text editor and add the two lines below:
define('WP_HOME','http://YourDomain.com/');
define('WP_SITEURL','http://YourDomain.com/');
Obviously you should replace “YourDomain.com” with the actual domain name of the WordPress site.
Happy hosting!
I recently decided to create a test/development instance of a WordPress site that I run. In part of doing this I had to deal with how to backup one MySQL database and restore it to another database. After that was done, and I copied over the content files, I had to tell WordPress where to find the new database and how to connect to it.
How is this done? Find the wp-config.php file that’s located in your WordPress site. Open that file in your favorite text editor (like WebMatrix) and look for the database connection settings, which will be near the top of the file (after a large block of comments). It should look like…
// ** MySQL settings - You can get this info from your web host ** //
/** The name of the database for WordPress */
define('DB_NAME', '*NameOfTheDatabase*');
/** MySQL database username */
define('DB_USER', '*NameOfTheDatabaseUser*');
/** MySQL database password */
define('DB_PASSWORD', '*TheDatabaseUserPassword*');
/** MySQL hostname */
define('DB_HOST', '*TheNameOfTheDatabaseServer*');
The sections are self-explanatory so just go through one line at a time and edit the fields to match the database server name, database name, username for the connection, and the password for the database user. Save the file and you should be good to load up your new WordPress site now.
Happy hosting!
Today I had to take a MySQL database backup from one database and then restore it to a different database name (for development/testing purposes). I tried a number of different tricks that I found online through Google without any success. The issue was that the user I was using to restore the data was NOT an administrator (root) on the database so it was failing with permission errors – always with an error related to the name of the database I restored FROM.
Okay, time to go old-school. So… I opened the .sql file that was created by the MySQL backup and behold – it’s text! How great is that!? Not some cryptic gibberish like a SQL Server database backup file format.
When looking at the file a little, right there near the top I found the issue. The MySQL backup files by default assume you want to restore to the exact same file name. So then have this line:
CREATE DATABASE /*!32312 IF NOT EXISTS*/ `test` /*!40100 DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci */;
In that line the database that I restored from was actually named “test”. As you can see, it checks for the existence of the database and if it doesn’t exist, it creates the database. Well, in this case I didn’t want that database created and my user didn’t have permissions to perform that action anyway.
So I changed the name of the old database (“test”) to match the name I wanted for the new database (“newTest”).
CREATE DATABASE /*!32312 IF NOT EXISTS*/ `newTest` /*!40100 DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci */;
Great – one error avoided! But thankfully, before existing the .sql file, I noticed the very next line in the file:
USE `test`;
Well, that’s no good. That’s going to use the ORIGINAL database that I performed the restore from. Yikes. If my user had permissions to that database it would have overwritten the original. Not good at all. So, let’s change that…
USE `newTest`;
I did a quick scan through the rest of the file and nothing stood out to me as an issue. I performed the restore (in this case using MySQL Workbench but any tool – even a command line – would have worked fine) and everything went nice and smoothly. Like magic I now have the data from the “test” database restored to my new database named “newTest”.
I hope this is helpful! Cheers, and happy hosting!
A client was getting errors when using PUT/POST/DELETE verbs on their web application recently.
The errors he was seeing were:
<h2>405 - HTTP verb used to access this page is not allowed.</h2> <h3>The page you are looking for cannot be displayed because an invalid method (HTTP verb) was used to attempt access
After some troubleshooting the error was isolated to the fact that WebDav was installed on the server and was intercepting those requests for its own service use.
Rather than removing WebDav from the server, we went looking for another solution. Thankfully someone on Twitter understood the issue and gave an example of changes to make to the client’s web.config file in order to disable (remove) the WebDav module for just that specific site without requiring any manual administrative actions on the server.
The code updates to make to your web.config file to resolve this error are:
<configuration>
<system.webServer>
<handlers>
<remove name="WebDAV" />
<remove name="ExtensionlessUrlHandler-ISAPI-4.0_32bit" />
<remove name="ExtensionlessUrlHandler-ISAPI-4.0_64bit" />
<remove name="ExtensionlessUrlHandler-Integrated-4.0" />
<add name="ExtensionlessUrlHandler-ISAPI-4.0_32bit" path="*." verb="GET,HEAD,POST,DEBUG,PUT,DELETE,PATCH,OPTIONS" modules="IsapiModule" scriptProcessor="%windir%\Microsoft.NET\Framework\v4.0.30319\aspnet_isapi.dll" preCondition="classicMode,runtimeVersionv4.0,bitness32" responseBufferLimit="0" />
<add name="ExtensionlessUrlHandler-ISAPI-4.0_64bit" path="*." verb="GET,HEAD,POST,DEBUG,PUT,DELETE,PATCH,OPTIONS" modules="IsapiModule" scriptProcessor="%windir%\Microsoft.NET\Framework64\v4.0.30319\aspnet_isapi.dll" preCondition="classicMode,runtimeVersionv4.0,bitness64" responseBufferLimit="0" />
<add name="ExtensionlessUrlHandler-Integrated-4.0" path="*." verb="GET,HEAD,POST,DEBUG,PUT,DELETE,PATCH,OPTIONS" type="System.Web.Handlers.TransferRequestHandler" preCondition="integratedMode,runtimeVersionv4.0" />
</handlers>
<modules>
<remove name="WebDAVModule" />
</modules>
</system.webServer>
</configuration>
I hope this help. Happy hosting!
Recent Comments