Blog Archives

review – at&t TILT

I have had the TILT with at&t for about a week now. I have to say this is the best phone I have used to date. Here are some highlights of why I like this device..

1. Its sleek and visually cool looking, coloring is modern and glossy.

2. The weight of the phone is indicative of being well built, it feels sturdy and tough.

3. It has plenty of onboard memory; you can customize the device, install apps and have plenty of onboard memory left without the need of a storage card.

4. Onboard GPS radio is neat; this is my first phone with true onboard GPS. A perk is that both Google maps and windows live search work with the onboard GPS radio for free.

5. The speed of this device to a data network is amazing. Over HSDPA I can download at nearly 1mbps which is not bad, although this connection is theoretically capable of much faster sped, but it’s still way better than EDGE!

6. You can use this device as a wireless modem, so when you travel or go somewhere that doesn’t offer free internet access, you can connect over Bluetooth to a laptop and get on the internet for free using your phone’s data plan.

7. Windows mobile 6 pro seems much more stable and visually attractive.

8. Battery life is not bad, in one day I am only using less than 50% of the battery with normal to light usage.

9. You can be on the phone and receive e-mail and use the data connection at the same time. No longer does using the phone disable all other radios on the device. You can now get important e-mail while talking on the phone.

10. Mobility! I can browse the web, make a blog post, track my position with GPS, take pictures, connect to wifi, use bluetooth devices, conect to VPN, run Citrix applications and sooooo much more, all while on the go.

There is more I will post about this device later, but those are the main points…

Advertisements

Monitor upgrade

Over the weekend, I received a free upgrade to an HP w2007 20″ widescreen LCD flat panel monitor for my home PC. Its a long story which I’ll comment on soon. This is a nice monitor, perfect for multi-use and the things hat we do with our computer. Its got a nice glossy black finish, which I was a little concerned about because it will be used in a shared area of the house, but after some use and testing its actually not bad. It gives images a nice shiny look. It has a 5ms response time and has a 1000:1 contrast ratio. Retail cost was $269.

Reforming Daylight Savings Time

I came across this amusing article a long time ago actually, it has an interesting take on Daylight Savings time:

———-

It happens every spring: crocuses, baseball (with any luck), and the switch to Daylight Savings Time (DST).

Coming off DST is not hard. In the Fall, we set our clocks back one hour. We all get an extra hour to sleep, and those who forget find themselves at church, or the airport, or wherever an hour early. Embarassing, but not catastrophic.

But in the Spring we set the clocks forward, and the trouble begins. We lose an hour of sleep. Forgetful people miss Mass, planes, breakfast, and the big game on TV. Some are thrown into disarray for up to a full week. Annual losses due to DST confusion have been estimated (by me) at over a million dollars. I myself have missed a flight to Washington and a showing of The Seven Samurai because of DST.

There is no need for such tragic waste. We can – we should and must – urge our lawmakers to reform Daylight Savings Time as follows: Setting clocks back is easy; setting them forward is difficult. Therefore, let us keep the fall ritual as it is. However, one Sunday each Spring, let us set our clocks not one hour forward, but TWENTY-THREE HOURS BACKWARD.

Think of all the advantages. We will not lose an hour of sleep; we will gain (almost) a day of rest. It will be Saturday all over again. You will never again miss Confession, or an airplane, or the Redskins game.

Naturally, if this were the whole plan, our calendars would fall behind one day in each year. However, the second part of the Revised DST Plan deals with this. Every four years, instead of adding a day, let us SUBTRACT THREE DAYS. Furthermore, let these be Monday, Tuesday, and Wednesday, which according to recent polls are the least popular days.

If done in February, which seems reasonable considering what a miserable month it is, this would have the beneficial side effect of shortening the excruciating presidential primary season by an effective four days.

The advantages of this plan are clear. Let us waste no time. With a determined effort we can have Reformed Daylight Savings Time by Spring of next year.

Write your congressperson today!

Christmas DVD mailout

Yesterday, we finally received the picture order for our 2006 Christmas Card mailers. Its a nice casual Christmas picture of our family on a glossy 4×6 with our new address and cell phone numbers on them. I have been waiting for about 2 weeks to get these, which is why we will be mailing them out late. Better late than enver! We are mailing them out to 3 families today or tomorrow, and sending a bunch to my mom to distribute. Its not as good of a video as I was hoping, but I’m sure people will still enjoy it.

Network and email issues

Next, I realized that my internet speed was very slow at home. I have a cable modem high speed internet account with Road Runner and also got the 10MB speed plan, so I should get close to 10MB down and 1MB up. After performing a speed test I found I was only getting from 200KB-600KB, which is obviously really bad. I submitted an online support ticket, but never did hear back. So I decided to do my own testing. I started to shut off my home computers/servers one at a time to make sure it wasn’t something on my home network causing the issue. I sthudown my backup server, ran another test, nope, that wasn’t it. I shutdown my exchange server, nope that wasn’t it. I shutdown my AD controller (sisko) and sure enough my speeds returned to normal. Sisko must have had some kind of issue that was causing severe network problems and slowing down my internet access speeds. I’m not sure if it was sending out data or receiving data, but it was flooding my network. I rebooted the server, disabled unneeded services, ran windows update, and checked for spyware/adware and found no problems. I assume its a symptom of a software issue in Windows that went haywire, or possibly the initial signs of a bad NIC or one thats on its way out. At least I know where to start looking now if it ever happens again.

So now both of my issues are resolved. I did make a few changes though, I implimented a secondary DNS service with rollernet for shorehost.com. I also got a new no-ip mail reflector account that does the same thing as rollernet, but it costs $$. I added this service to shorehost.com and churchgang.us. This should prevent any further loss of mail or service interruption in the future. I now have 4 backup MX records in my DNS zones for both domains, and this should provide way more redundancy than I really need. ]]>

TECH: Exchange Migration and permissions testing

Introduction

This posting will review the approach taken in a test environment to accomplish a simulation migration of our existing NT4 domain to server 2003 with Exchange 2003. All work was done offline on a private network IP scheme on an isolated switch to prevent communication problems with the production network. Access was limited to a hardwired laptop and a test desktop. Testing was performedwith a user/mailbox on Exchange 5.5, and another user/mailbox on Exchange 2003. Migration Process

The following are the steps in order that were used to perform a test migration of the NT4 domain. Directory exports from Exchange 5.5 were used to re-create the Exchange 5.5 Directory in a test environment.

Server Setup

? Initial NT4 PDC was create for the domain utilizing VMWARE and was updated to SP6A. Names utilized were duplicates of production network.
? Two additional NT4 BDCs were created;one to simulate a BDC, the other was create to perform the upgrade to Server 2003 and AD. Both were installed as BDCs and were updated to SP6A.
? Three NT4 member servers were created for use with Exchange 5.5. All were installed as member servers, and updated to SP6A. Each server was named the same as in production.
? Exchange 5.5 was installed on a member NT4 server, creating a duplicate of our existing Exchange 5.5 system. Org and site names were duplicated from Production.
? Exports of the Exchange Directory were imported and were also used to create the NT4 user accounts/mailboxes used in production. This populated the NT4 user database with usernames and blank passwords. New Mailboxes were created for users on their respective servers
? A test workstation was setup on the test NT4 domain. An exchange outlook profile was created for the exchange 5.5 user.
? Tests were performed to verify that DLs and inter-org mail flow was working.
? The last NT4 BDC that was created initially was promoted to a PDC (automatically making the original PDC a BDC).
? The OS on the new PDC was upgraded to Server 2003.
? The Active Directory Installation Wizard was run to upgrade our domain to AD.
? The AD wizard installed DNS locally on the PDC, but HOSTS files were still maintained on all NT4 servers, just as in production.
? A desktop was hardwired to the isolated switch and setup as an AD-client using a user account in AD. This was to verify that AD had successfully upgraded our NT4 domain to AD.
? A new server was installed also using VMWARE using server 2003 operating system. Server was installed as a member server of the AD domain. This was for use with the migration to Exchange 2003. SP1 was installed on the server and all updates and patches were applied.
? A temporary OU was created in AD to house the objects from the ADC replication process.
? Exchange 2003 was installed on this new 2003 server, along with the ADC and SRS. This new Exchange 2003 server was joined to our existing Exchange 5.5 site.
? The ADC replicated all Exchange 5.5 objects such as DLs, custom recipients, etc, into AD. The DLs were replicated to AD as universal distribution groups.
? Testing was performed between Exchange 5.5 users and Exchange 2003 users to verify mail flow and DL functionality. All tests completed successfully. No loss of public folder permissions was experienced. Although error 9552 in the Exchange 2003 server event log was experienced. But no loss of permissions was observed.

The above information was a test of a migration approach for an NT4 domain to Active Directory in a mixed mode domain. DLs are used in Exchange 5.5 public folders as security objects. Technically, when the ADC replicated the Exchange 5.5 DLs to AD as Universal Distribution Groups, once a user accesses a public folder where a DL is used as a security object, that Universal Distribution Group should automatically get converted to a Universal Security Group. However, since our domain is in mixed mode, this conversion failed. The result should have been a loss of all permissions on the public folder in question, leaving only the owner with any permissions to the folder. What I found in this test is that everything still worked, users of both Exchange 5.5 and Exchange 2003 were able to use the public folders without a problem. I called Microsoft support on this issue and they were not able to explain why this worked, as they agreed with their KB articles that it should have caused permissions problems on all public folders using DLs on the client permissions of public folders.]]>

TECH: Authrest on Exchange 5.5

Original Problem???

In early March an initial attempt to install Exchange 2003 into our existing Exchange 5.5 site was attempted. However, an unanticipated disaster followed this attempt that resulted in the contents of the Exchange 5.5 Directory on all Exchange 5.5 servers to be removed. This resulted in loss of functionality of all DLs and loss of custom recipients.

The Exchange Directory was eventually restored from backup on our primary Exchange 5.5 Server, however we quickly noticed that the restored Directory was not replicating back to the other Exchange 5.5 servers. I was able to find an old application called authrest.exe that can be used to increase the USN (unique identifier) of the Exchange Directory on a server to force it to be the authoritative Directory Server. This will force Directory informationto be replicated to the other Exchange servers. This process was run on our primary Exchange 5.5 Server which did allow the Directory information to replicate back to the other Exchange servers. Shortly after this we noticed that changes made to Exchange objects on any other server but our primary Exchange 5.5 Server would not replicate back to our primary Exchange 5.5 Server. This was because Bobafetts USN was increased beyond the USN of the other servers, and was so far ahead and the changes on the other servers did not exceed our primary Exchange 5.5 Server USN and therefore would not replicate to our primary Exchange 5.5 Server. Changes made on our primary Exchange 5.5 Server would replicate to the other servers without a problem. I did however notice several side effects of restoring the Exchange Directory on our primary Exchange 5.5 Server. First, Backup Exec stopped working. I started getting Access deniederrors on the backup jobs. Permissions were checked for the backup exec account used to run the backup jobs, and no problems with the permissions were found. I tried using other Exchange admin accounts but I still received Access Denied errors. I then tried creating a new user account, and followed the Microsoft guidelines for assigning a backup account permissions to an Exchange organization. This also did not work.

As a last resort, I tried using NTBACKUP and I found that NTBACKUP was able to access Exchange and proceed to backup the exchange information on our primary Exchange 5.5 Server. I have been running manual backups on our primary Exchange 5.5 Server since then. Apparently something in the restore process of the Exchange Directory on our primary Exchange 5.5 Server has caused some type of problem with Backup Exec. We are running the latest version that is compatible with NT4, so upgrading is not an option.

Synchronization Information???

On Friday, March 31st, another sysadmin and I began running authrest on all exchange 5.5 servers in hopes that authrest would set the same USN on all Exchange 5.5 servers to the same level. This would effectively force all Exchange servers Directories into synch. This theory was based on the emergency recovery documentation that was used during the initial problems in early March.

We ran authrest with an increase value of 101000 on each Exchange server. After the reboot, I tested to see if the replication issues were fixed. I modified a DL by removing my user account from the DL. I then checked that the changes replicated to all other exchange servers. I found initially that it did, so it appeared that the process fixed the replication issues.

Upon further testing and someverification it was verified that the Directory Synch issues are indeed not corrected. Changes made on other Exchange servers are still not replicating to our primary Exchange 5.5 Server. I began to do more in depth research on the authrest application andtried to find more operational details. What I found is that Authrest only increases the existing USN on the Exchange Directory and its objects, it does not reset the USN to the specified value you use when running the application. What this means is that we only accomplished increasing the USN on the Exchange 5.5 servers by 101,000. They are still not in synch. our primary Exchange 5.5 Server replicated the same directory information back to all other Exchange 5.5 servers; authrest did not bring them all to the same level as was previously thought.

Options

Currently our primary Exchange 5.5 Server is still acting as the authoritative Directory server in our Exchange organization. Its USN is the highest among all of our Exchange 5.5 servers. Based on this updated information, here are the options that we have in dealing with this situation…

1. Continue to use our primary Exchange 5.5 Server as the master Exchange 5.5 Directory server. All changes to all exchange objects should be made on this server. This includes DL membership modifications and new user mailbox creation. (Mailboxes for other servers can still be created on our primary Exchange 5.5 Server, under the advanced tab of the new mailbox wizard, simply select the home server you want the mailbox created on).
2. Exchange logs an event to the application log during replication of the Exchange 5.5 Directory. We could identify each servers USN level (or number), then based on these results, use authrest to increase each servers USN to a specific number with the goal of individually increasing each other Exchange 5.5 server to thesame number. So authrest would be run with different increment numbers based on that servers existing USN number. Using this method we can correctly use authrest to re-synch the Exchange 5.5 Directory.

I recommend option 1. I dont see any real need to cause further exchange downtime to fix an issue that wont cause us any problems in the Exchange 2003 migration. I can live with running manual backups on our primary Exchange 5.5 Server until its replaced. Backup and restore on our primary Exchange 5.5 Server using NTBACKUP was verified to be working.

Summary Information???

The emergency documentation used to restore the Exchange 5.5 Directory in early March did not include the functional information on authrest that is now known. The attempt that I made to re-synch the Directory was based on the information I had of authrest from the emergency restore that was performed earlier. It took several hours of research to find more information on this tool as it relates to Exchange 5.5. Most of the available information is in reference to an updated version that runs on Exchange 2003. Only passing references to this tool were located. Since support for Exchange 5.5 has ended, its been increasingly difficult to find information on Exchange 5.5.

Continuing to use our primary Exchange 5.5 Server as the authoritative Directory server will not adversely affect the Migration to Exchange 2003. If all changes to Exchange 5.5 objects are made onour primary Exchange 5.5 Server, it will always have the updated and correct Directory information. We can then proceed as planned and use our primary Exchange 5.5 Server in the ADC connector as the source of Exchange 5.5 Directory information to be imported into AD and Exchange 2003. By using option 2 above, any exchange 5.5 servers could be used for the ADC connector, but only 1 server is needed. ???

Once Exchange 2003 is successfully implemented for the first time, it will be much easier to add more servers later on. We can then migrate users and other Exchange 5.5 objects to Exchange 2003. From that point on, most of these issues we have been experiencing lately should be a thing of the past. The new infrastructure will prove to be much more resilient and easier to work with.

NOTE: Changes made on our primary Exchange 5.5 Server may not be immediately visible on the other Exchange 5.5 servers. Replication should take place within 5-15 minutes. A manual directory refresh can be done through the Exchange Administrator by highlighting the exchange server you want to update, double click on the Directory Service, and then click Update Now. Choose the option to update only new or changed items. Then click ok. This will force the remote server to update its Directory.

Thanks for reading! Hope this helps someone!]]>

Backups backups backups

After about 9 years of being in IT, I’ve learned how important backups are. I’ve experienced data loss due to not having a good backup several times. It really is worth it to have a good backup plan. Whether at work or at home. At home, I’ve got two 2003 servers, two XP desktops and I always make sure I at least make a ghost image of each one, with just the bare OS and again with all the software I need loaded. For example, my home PC, last night I was having troubles due to some beta software I installed (foolishly). I had planned to use my other XP desktop for software testing, but never seem to do that. The junk always goes on my primary PC, after all its faster and resist crashing longer than the slower desktop. So anyway, long story short, I decide to restore a ghost image of my Home PC with all the software loaded on it. Since I have a domain, my user accounts are still OK, I keep all my data on separate drives and network locations, so I won’t loose anything. But there always seems to be something you forget. Items like desktop downloads, favorites, RSS feeds, etc. now I couldn’t get windows explorer to work long enough to copy anything, so I got out my trusty Knoppix 3.9 bootable CD, inserted my thumb drive, and off I went, I was able to use Linux to get my data off my drive, before I reloaded the ghost image. I finally around 11pm, got all the stuff copied over and my ghost image restored. All I had to do was setup our desktop profiles again, like setting up outlook, and redirecting the my documents folder. Then I was done. So I’m all back up and running, thanks to having a good backup strategy. It only took 4 minutes to restore the ghost image, if I had to reinstall windows and all my apps manually, it would have taken hours! I use NTBACKUP to backup my two servers. The other desktop I don’t care about and will likely give away soon anyway.

Once I lost 2 years of data on a Novell Netware server I had at home. I decided I’d break a mirrored volume in Netware, forgetting I had stuff on it. Once it was broken, my data was gone. Boo hoo hoo. I was recently using a Dell PowerVault NAS 705N for my storage needs, but its a little slow, it was RAID5 which was good, but I decided to sell it, so now its listed on eBay. I hope I can sell it and get another 400GB hard drive. I have about 1TB of storage space in my PC right now. I need it too, I’ve got 200GB of normal data, like CD images, software, downloads, documents, etc. Then I have lost of multimedia, like music, movies, home video recordings and such that take up a lot of space. So I need to get one more drive and that should do it for now. My only concern now is that if any one of these drives fail, I loose all my data, and I don’t have a location on my network with storage large enough to store all that data if I were to back it up. I thought about getting a tape drive, but don’t want to spend the money (that I don’t have) on a tape backup solution which would likely not be large enough to hold all my stuff on a single tape anyway.
]]>

Company Migration Project

1. Little to no end user interruption
2. No loss of email connectivity
3. All work must be done by internal IT staff
4. No third party tools can be used

Existing Network:

1 NT4 PDC in NYK and 1 NT4 BDC in Switzerland. Two Exchange 5.5 servers in NYK, one in Switzerland and one in Hong Kong. There are also various software packages that sit on top of the Exchange infrastructure that must remain intact, such as RightFax (email faxing), Goodlink (mobile email) etc. Exchange is installed on member servers, none of the Exchange servers are installed on a PDC/BDC.

Desired result:

2003 Active Directory Domain with Exchange 2003 Enterprise Edition. Exchange servers will be in two-server clusters. 4 hub offices will house the Exchange clusters.

Migration Path:

In order to accomplish the above design goals and satisfy all the requirements, taking into account the existing network infrastructure, the following design should prove to be successful.

First, we will install a new server into our existing NT4 domain and make it a BDC for the domain. We will then, promote the new BDC to a PDC and allow time for replication. Once replication is complete, we will take the old PDC offline (by unplugging network connection or shutting down). We will then upgrade the new NT4 PDC to Server 2003 and run DCPROMO to install Active Directory. This process should preserve all existing user accounts, machine accounts, groups, permissions, etc. So far we satisfy all requirements.

Next, we upgrade or replace all existing NT4 BDCs. Once all NT4 servers are removed, we can then upgrade our new Active directory domain to Server 2003 Native Mode. As no more NT4 servers will be participating as domain controllers.

NOTE: During this time, all existing Exchange 5.5 servers will be maintained as NT4 member servers of the 2003 domain. Exchange 5.5 will continue to handle mail for us until the upgrade to Exchange 2003.

Exchange 2003 Migration:

For this part, we will install our first Exchange 2003 server (on a 2003 Enterprise Edition server installed as a member server) into our existing Exchange 5.5 site. To the exchange site, we are just adding a new server. The Exchange deployment tools will walk us through installing the Active Directory Connector and all necessary connection agreements. The SRS will also be installed. One Exchange 2003 server per hub office will be installed initially. Once we verify that the ADC is working properly and the “Move mailbox” wizard is available, all Exchange 5.5 user mailboxes will be moved to an Exchange 2003 server. Once all Exchange 5.5 mailboxes, public folders, distribution lists, custom forms, etc, are replicated over to the new Exchange 2003 servers, the existing Exchange 5.5 servers will be shut down to verify connectivity and that no “behind the scenes” issues exist. Once our Exchange organization has been verified to be functioning correctly with no further references to the Exchange 5.5 servers, we can then begin to de-commission them. This will be done by removing all references to Exchange 5.5 as replication partners on all public folders, and other exchange resources. Then the servers can be deleted from the Exchange 5.5 server administrator.

During this migration process, the only end user interruption noticed will be during the move mailbox process, as users will be logged out of their exchange mailboxes during a mailbox move. Mail flow is not affected since we installed Exchange 2003 into our existing Exchange 5.5 site, so the routing group is the same. The only remaining task to complete is something I left out above. Before Exchange 5.5 can be shut down or de-commissioned, the SMTP connector will need to be moved from one of the Exchange 5.5 servers to one of the Exchange 2003 servers. Once this is complete, and mail flow has been verified, then the Exchange 5.5 servers can be removed.

The end result is a quick, efficient migration/upgrade to Server 2003 and Exchange 2003. A final note here is on Clustering. The reason we did not use our clusters to install the first Exchange 2003 server is that there are certain components of Exchange that will not function on a cluster. Such as the SRS and ADC. This is why we will be using a standalone server in all hub offices for the initial move to Exchange 2003. Once we have Exchange 2003 up and running globally, we can then introduce our Exchange 2003 Clusters and then move mailboxes once more to the clusters. Once finished, the SMTP (bridgehead) can be moved to the appropriate cluster and the initial Exchange 2003 standalone servers can be removed.

The initial plan was to do a parallel migration, basically creating a whole new system in parallel to our existing system. This plan has many problems and would not have worked for us. End users would have received all new machine profiles, outlook profiles would have been lost, etc. This would have created too much work for our internal IT staff and caused too much interruption to end user connectivity. Not to mention mail flow and interoperability with Exchange 5.5 and Exchange 2003 is much more complicated when installed in separate Exchange Organizations. Third party tools would almost certainly be needed to maintain the level of co-existence we would have needed.
]]>