I can almost hear the "suckage".

Even though I am not a web designer, I get several dozen requests a year to relocate a customer's website to a new hosting provider. This is something I am happy to do for a customer if they have a relatively simple website, otherwise I refer them to a web design firm. Some things you want to consider before accepting this task are:

*see comment above about not being a web designer*

1.) Forms: Does the website use any custom forms? This is an important piece of information to know because these forms can sometimes be tricky. What I mean is that if the previous host has a public CGI-BIN folder where scripts reside and it sits outside of the website's directory structure, you may need to snarf this file manually in order for the form to work correctly once you have fork-lifted to the new host. You may have to enlist a Web Designer for assistance getting forms working on the new host.

2.) Microsoft FrontPage Extensions: Just hearing this phrase makes me gag. I am going to go ahead and put out there that I hate Front Page Extensions. Basically it is code that sits on your webhost that allows for one click, live changes to your website from Frontpage (which is no longer called Frontpage). If your customer is used to using this "feature", you want to make sure the new host supports this. Better yet, you could explain to your client that Frontpage Extensions have been riddled with security holes and there are better, and debatably more modern ways of handling the uploading of changes to your site like <gasp> FTP. Front Page Server Extensions' last version was released in 02'.

3.) Coding: Any good web host should offer a plethora of feature sets for your site. Some sites are written using PHP and others ASP. Either one of these technologies require that the hosting server support them if they are to be rendered correctly in your browser. *see above comment about not being a web designer* I have seen hosts that require that you toggle one or the other 'ON' in order to utilize them. There is typically some kind of hosting control panel (like CPANEL) to manipulate specific features of the hosting server.

When you have considered these things and you are ready to move forward, there is a great application called HTTrack that I have used for years to make "offline" copies of websites. Basically what this program does is crawl the site's code and suck down the site to a local directory. The program is simple and intuitive; once you have the site copied, you browse through it to make sure everything is there-intact. Once this is confirmed, you can log in to your new hosting provider and upload the site. The only drawback to HTTrack is that it does add comment tags in all of the HTML documents that this site was copied by HTTrack; you could edit this out but it would take quite awhile. Once you have uploaded the site, simply change the WWW and @ 'A' records in DNS to point to the IP address of the new host.

As an aside; in my experience, DNS is one of the most commonly misunderstood Internet technologies. This has been especially apparent when Web Designers contact me on behalf of my customers and start talking DNS to me. It is amazing to me how many people do not understand this technology. We have more problems caused by DNS changes made by Web Designers who do not understand the technology well enough than one would believe. I just thought I'd throw that out there; I am sure I am not the only IT consultant / network engineer that has had that experience.

SQL 2005, SSIS and maintenance plans.

I ran into an instance today where I had deployed SQL 2005 Standard edition (using default options) onto a server that was going to be a dedicated server for a line of business application for one of my clients. Once the software vendor had migrated the database onto this server and configured the LOB app accordingly, I was tasked with setting up a maintenance plan and just generally finessing the configuration (enabling Shadow Copy etc..). When going through and configuring the maintenance plan, I received an error that stated:

<snip>
TITLE: Maintenance Plan Wizard Progress

Create maintenance plan failed.
-----------------------------

ADDITIONAL INFORMATION:

Create failed for JobStep 'Subplan'.  (Microsoft.SqlServer.MaintenancePlanTasks)

For help, click: http://go.microsoft.com/fwlink?ProdName=Microsoft+SQL+Server&ProdVer=9.00.1399.00&EvtSrc=Microsoft.SqlServer.Management.Smo.ExceptionTemplates.FailedOperationExceptionText&EvtID=Create+JobStep&LinkId=20476

------------------------------
An exception occurred while executing a Transact-SQL statement or batch. (Microsoft.SqlServer.ConnectionInfo)
------------------------------

The specified '@subsystem' is invalid (valid values are returned by sp_enum_sqlagent_subsystems). (Microsoft SQL Server, Error: 14234)

For help, click: http://go.microsoft.com/fwlink?ProdName=Microsoft+SQL+Server&ProdVer=09.00.1399&EvtSrc=MSSQLServer&EvtID=14234&LinkId=20476
</snip>

Of course, as I have found to be the case typically, the links provided in the error dont turn up much of anything useful. I then proceeded poking around Google and I found that this error occurs when creating a scheduled maintenance plan in an installation that is lacking SSIS (SQL Server Integration Services). This is documented as a known issue under KB909036. I followed the instructions in this KB article and found that it worked flawlessly once I has SSIS installed.

USB drive affecting server reboot.

I had an instance where I configured patching for one of our clients. The patching mechanism would cause the server to reboot automatically-as necessary at the scheduled patching time. The problem was that, when it rebooted, it never came back up. I contacted the client and found that the only way to get it back up was to unplug the attached USB backup drive and power cycle. I could plug the disk back in once the system had gotten past the first few stages of the boot process.

I made sure USB support was enabled in the BIOS; it was. I also noted that during P.O.S.T it would detect this device. I consulted my buddy Google and found this post from one of the SBS MVPs, Kevin Weilbacher. I followed the steps as defined in that post and I was able to successfully boot the machine with the drive attached!

Thanks Kevin!

Changing the 'Administrator' password...

Changing the Administrator password is a pretty common and simple task. As it would seem in almost all IT oriented tasks, there are easy things to overlook. I suggest following these steps to be sure you have covered all the necessary bases.

 

1.) Services: Open the services management console and sort by “Logon as”. Any logging on as Administrator need to be changed to the new password. This can be accomplished by right-clicking the respective service and inputting the proper password in the correct location in the “Log on” tab.

2.) Scheduled tasks: I forget these all the time. We need not worry about the default SBS tasks and volume shadow copies as this runs under the system account. However, if there are custom scheduled tasks (like Robocopy scripts), they will need to be changed. This process is very similar to the services, you right click the task and on the main tab there is a button that says “set password”; should be self-explanatory from there.

3.) Kaseya credentials: This also needs to be changed in order for certain Kaseya tasks to complete successfully. This can be altered by selecting the respective company’s machine group, going to the agent tab and using the “Set Credential” function. Make sure to select only the PCs in the subnets covered by the server so as not to potentially change any home computers or otherwise, non-domain machines that may be managed; these machines need to retain the local administrative credentials. Once you have changed the credentials here use the test button located at the top right to ensure everything is properly input. If this isn't done correctly-patching, backups, and certain scripts will fail to execute properly.

4.) Server Reboot Test: In cases where you are unsure of in-place configurations, it may be a good idea to reboot the server to make sure everything comes back up properly.

 

Following these guidelines should ensure that everything is copasetic once you have changed the password.