Partition type 0xee is a dummy entry in a MBR partition table, telling non-GPT-aware things that the disk is occupied by something they won't understand.
The version of GRUB in RHEL 5.5 will not understand GPT-style partitioning: it will only know about MBR.
If you need to support systems that are this old, the standard recommendation is to virtualize them if at all possible. Virtualization will normally give you tools to present disk space to the VM in ways that are not tied to the size of the actual physical disk(s). In this case, you could present the 4 TB disk as multiple virtual devices, each sized at 2 TB or less.
If you cannot virtualize this system, there is one dirty hack that might be possible. Do not attempt this without making sure you'll understand the procedure and its effects. If you upgrade your hardware to something that supports GPT at the firmware level, this setup is likely to stop working... but then you'll have new ways to solve your problem anyway.
First, make a GPT partition table with the partitions you want. The partition that contains your /boot directory (= usually, either your root filesystem or a dedicated /boot filesystem) should be fully within the first 2 TB of the disk. Make a note the exact start & end block numbers of this partition. Set the GPT partition type to regular "Linux filesystem" on each partition.
When creating a GPT partition table, gparted will have also created a "protective" fake MBR partition that has type 0xee and covers the entire disk starting from block #1 and ends at the maximum possible value for MBR, at 2 TB.
The next step is to carefully edit the MBR partition table using fdisk so that it has one partition that has MBR partition type 0x83 and its start & end block values exactly match the first partition specified in the GPT partition table. You can even mark this MBR partition as active, so that the BIOS will assuredly detect the disk as bootable. The second partition entry should cover the rest of the disk (up to 2 TB) and have type 0xee.
Now, you'll have a hybrid partitioning scheme, in which the first partition will be recognizable by both MBR and GPT partitioning schemes, but the second partition (the one that goes beyond 2 TB) will only be valid under a GPT partitioning scheme.
When installing GRUB 0.97 on such a disk, you must remember that you cannot embed GRUB stage1.5 into the area after the MBR and before the beginning of partitions, as this area is where the GPT partition table lives. You don't want to damage it. To make sure this does not happen, you may need to use the install command in the GRUB shell to install the bootloader, rather than rely on automation provided by grub-install or the setup command of the GRUB shell.
Now, when the system is booting, the BIOS should see a valid MBR with one valid, bootable partition (and one strange 0xee thing it can ignore). The BIOS will read the MBR and execute the boot code in it, which will be the first stage of GRUB 0.97.
GRUB will now use the BIOS functions to load its second stage from a pre-recorded position within the first partition, then activate its own filesystem support (still using BIOS functions for low-level disk access) and read the menu.lst file, and the Linux kernel and initrd files from the specified "GRUB root partition", and start the Linux kernel. At that point, GRUB's job is done.
Now, the Linux kernel starts up and loads its own storage drivers from initrd. Unlike the BIOS, Linux can now address the full capacity of the disk and understand the GPT partition table (RHEL has had GPT support starting from RHEL 4). As a valid GPT partition table exists, the MBR is secondary and will be ignored. Linux will see and be able to use both partitions.
