Tony

What I'd recommend you do is upload the export file to your webspace with us and make a ticket asking us to import it into the database. We can do it via command line and at least be able to rule out that importing portion is causing the encoding issues.

Date: Saturday November 29th 2008 (11/29/2008) Start time: 2:00am CST End time: 5:00am CST Devices: all CERs, all DARs, all FCRs Location: DAL01 Duration: 3 hours Services Effected: Public Network, Dallas ================================================== Datacenter Engineers will be conducting BGP maintenance on all CERs, all DARs, and all FCRs on Saturday November 29th starting at 2:00am CST. While there is no expected downtime, customers may experience brief packet loss and/or high latency while routes reconverge through each redundant, edge router. Although we expect these changes to only take approximately 60 minutes, we have scheduled a maintenance window from 2:00am to 5:00am CST. ==================================================

Date: Saturday November 22nd 2008 (11/22/2008) Start time: 3:00am CST End time: 5:00am CST Devices: cer01.wdc01, cer02.wdc01, fcr01.wdc01 Location: wdc01 Duration: 2 Hours Services Effected: Public Network, WDC ================================================== Datacenter Engineers will be conducting BGP maintenance on Customer Edge Routers 01/02 and Frontend Customer Router 01 on Saturday, November 22nd starting at 3:00am CST. While there is no expected downtime, customers may experience brief packet loss and/or high latency while routes reconverge through each redundant, edge router. Although we expect these changes to only take approximately 15 minutes, we have scheduled a maintenance window from 3:00am to 5:00am CST. ==================================================

How did you generate the export file? The SQL within it should have the encoding information for the tables. Depending on if you used something other than say phpmyadmin it may remove the encoding portions. The other possibility is if you downloaded it to your computer and opened it you may have converted to something other than utf-8

This was completed on 11/11/2008

This maintenance was completed on 11/04/2008.

Another vote for FileZilla

This has been completed. The server was down for less than 5 minutes while it was rebooting.

Rebooted without issue was down for less than 5 minutes.

Small delay with this update we're going to be rebooting the machine right now it should take no more than 10 minutes to reboot.

This was completed a little while ago. It was down a bit longer than expected due to some issues with the console. But once we fixed that it was fine.

Dallas: traceroute to 200.149.113.29 (200.149.113.29), 30 hops max, 40 byte packets 1 (74.86.66.193) 118.348 ms 118.329 ms 118.319 ms 2 po101.dar01.dal01.dallas-datacenter.com (66.228.118.153) 0.327 ms 0.343 ms 1.253 ms 3 po1.cer02.dal01.dallas-datacenter.com (66.228.118.204) 1.243 ms 1.236 ms 1.225 ms 4 s261524-internet.dan.savvis.net (208.175.175.9) 1.247 ms 1.239 ms 1.228 ms 5 dpr1-ge-2-0-0.dallasequinix.savvis.net (204.70.204.146) 1.151 ms 1.142 ms 1.132 ms 6 * * * 7 204.70.197.178 (204.70.197.178) 33.948 ms 33.935 ms 33.909 ms 8 bpr2-so-7-0-0.miamimit.savvis.net (208.172.97.170) 28.840 ms 28.863 ms 28.854 ms 9 208.172.96.226 (208.172.96.226) 177.688 ms 177.682 ms 177.672 ms 10 200.223.254.105 (200.223.254.105) 152.641 ms 152.836 ms 152.770 ms 11 * * so-0-1-0-0-mpi-mg-rotn-01.telemar.net.br (200.164.197.214) 157.830 ms 12 200.149.113.29 (200.149.113.29) 154.810 ms 294.325 ms 154.256 ms [/code] Washington DC: [code] traceroute to 200.149.113.29 (200.149.113.29), 30 hops max, 40 byte packets 1 (208.43.114.49) 0.404 ms 0.391 ms 0.380 ms 2 po101.cer01.wdc01.washingtondc-datacenter.com (208.43.118.133) 0.534 ms 0.528 ms 0.531 ms 3 border1.tge7-3.tkt270641.wdc008.pnap.net (66.151.100.65) 0.497 ms 0.496 ms 0.670 ms 4 core3.te5-1-bbnet1.wdc002.pnap.net (216.52.127.32) 0.899 ms 0.893 ms core3.te5-2-bbnet2.wdc002.pnap.net (216.52.127.96) 1.105 ms 5 ip70-167-150-61.at.at.cox.net (70.167.150.61) 1.597 ms 2.809 ms 1.052 ms 6 ashbbbrj01-ae0.0.r2.as.cox.net (68.1.0.220) 1.516 ms 1.646 ms 1.597 ms 7 * * * 8 204.70.197.177 (204.70.197.177) 35.940 ms 35.668 ms 35.910 ms 9 bpr1-so-4-0-0.miamimit.savvis.net (208.172.99.94) 28.628 ms 28.857 ms 28.849 ms 10 208.172.96.226 (208.172.96.226) 123.512 ms 123.992 ms 123.720 ms 11 200.223.254.105 (200.223.254.105) 133.191 ms 133.413 ms 133.402 ms 12 * pos10-0-mpi-mg-rotn-01.telemar.net.br (200.223.131.213) 139.119 ms 138.879 ms 13 200.149.113.29 (200.149.113.29) 134.359 ms 133.879 ms 134.086 ms 20ms is going to make very little if any difference. As for doing it. It was something we offered when we started the location. But at this point you'd need to make a ticket and we'd need to evaluate if it's possible.

What customers usually do in this case is download a copy through phpmyadmin at their old host then upload the database to their ftp account with us. After they've done that they make the database the data should be imported into and make a ticket asking for us to restore the data from the file they uploaded.

We will be updating the Skyline server kernel to the latest version on Friday October 31st at 9:30am EST. We estimate this will result in about 10 minutes of down time while the server reboots. Keeping kernels up to data is a necessary step in order to stay on top of performance improvements as well as have the latest security fixes. Date: 10/31/2008 Start time (EST): 9:30am End time (EST): 10:00am Duration: 30 minutes Estimated Down Time: 10 minutes

We will be updating the Saturn server kernel to the latest version on Thursday October 30th at 10:00am EST. We estimate this will result in about 10 minutes of down time while the server reboots. Keeping kernels up to data is a necessary step in order to stay on top of performance improvements as well as have the latest security fixes. Date: 10/30/2008 Start time (EST): 10:00am End time (EST): 10:30am Duration: 30 minutes Estimated Down Time: 10 minutes

We will be updating the Neptune server kernel to the latest version on Thursday October 30th at 9:30am EST. We estimate this will result in about 10 minutes of down time while the server reboots. Keeping kernels up to data is a necessary step in order to stay on top of performance improvements as well as have the latest security fixes. Date: 10/30/2008 Start time (EST): 9:30am End time (EST): 10:00am Duration: 30 minutes Estimated Down Time: 10 minutes

Turned out the support area account was not activated. Crazy support system ... I also found more references to the old support system in the client area which I removed. It'll be a nice day when we have our own integrated system running all of this stuff.

Send me a private message on the forum with the information it's sending you in the email.

Are you using the login it sent you? As this login will not match our client area. It will be an email address for the username and the password it sent to you. Also make sure if you're copying it from the email it sent to you that you're not copying any extra characters you cannot see. Sometimes that's what ends up happening so pasting the login into notepad gets rid of that so it's just the text and nothing else.

Not a problem our fault for leaving something referencing the old support system. I'm assuming you now have our replies so you'll be able to troubleshoot the problem with us now through our ticket system.

Our support area is at https://www.hawkhost.com/support and all the links to the billing systems support system should be removed which I'm guessing you found a link where that was not the case. Also every reply we give you in a ticket is sent to your email address. Now if you're using say yahoo or gmail it might sometime end up in your junk mail folder. I looked up your two tickets and both had replies in under 30 minutes.

Just to be on the safe side the status of the raid array was checked when it was rebooted. It looks fine so we're most likely going to need to run a fsck. Based on what we saw when we were able to get into the machine it's going to need to be run on /var but obviously we do not know for sure until we're booting back into the operating system.

The machine is currently being rebooted... We were unable to do any meaningful diagnostics so we're hoping a reboot should help make that possible.

I have not seen that set of errors before. I'd recommending making a ticket so that we may look at the server you're on in case it's causing the error. I'd include the information you're using for outlook. So the mail server and username as well as the ports and what you're using (IMAP or POP3)

This work has been completed.