When you say "issued keys," do you mean activation keys to be used with
rhnreg_ks?  Who issued the keys to you?

Are you an org admin for the org tied to the activation keys?

Bill is using 'product IDs' for use at www.redhat.com/now that were issued to
partners in order to grant access to the RC.

Bill -- you need to activate one product ID (e.g. the 16-character code) for
_each_ system you register.  Also, make sure that you use the same account name
when you activate at www.redhat.com/now and when you register your system to
RHN.  Can you check that you've done both of those?

I have 2 keys assigned to me now under the same email address
as my user name.  I noticed when I run up2date
I get this too:

Traceback (most recent call last):
  File "/usr/share/rhn/up2date_client/gui.py", line 1035, in onSendPageNext
    self.channels = rhnChannel.getChannels()
  File "/usr/share/rhn/up2date_client/rhnChannel.py", line 145, in getChannels
    raise up2dateErrors.NoChannelsError(_("This system may not be updated until
it is associated with a channel."))
up2date_client.up2dateErrors.NoChannelsError: This system may not be updated
until it is associated with a channel.

I'm going through a proxy too...

I'm the activation key gatekeeper here at Sun.  Bill has so far tried the following:

1.  Adding additional keys to the group account.
2.  Turning off any machines with that same hostname (i.e. turning their
entitlements OFF).
3.  Setting a different hostname.

None of these has produced a different effect.  My understanding is that:

1.  These folks are supposed to be able to pull from our pool of keys (as other
RH distros do).
2.  Machines are supposed to show in both the origin user's RHN account, and in
the group one.
3.  Machines probably aren't supposed to show multiple times (you'd either get
an error or the last entry would "win".

None of these things are happening.  While we can put a management system in
place to handle item 1 (though 25 keys will then be woefully insufficient for
testing--our QA guys like Bill do tests that require rebuilds on the same box as
many as 10 times per DAY), item 2 is really a showstopper (we'd need to assign
an FTE just to sit on https://rhn.redhat.com and manage systems?  Please.). 
Item 3, frankly, would frankly be merely annoying if users could turn off their
own entitlements.

*** Bug 106591 has been marked as a duplicate of this bug. ***

There appear to be sufficient entitlements and I was able to register a system
successfully to this account. There should be no order dependence for
registration of entitlements on www.redhat.com/now and registration of the
system profile with rhn.redhat.com. 

At this point all you should need to do is run:

up2date --register

check the "register to existing account radio button, and give it the username
"bill.palos@sun.com" and the password ... then all the Finish/Next buttons you
can find :). 

After snooping around I realize I have 2 accounts that use the same email
and I do get the system to show when using my email as the username, but
that was not the intented account i was expecting it to show up in. As far
as I can remember I don't recall being able to sign up more than once with
RHN under the same email address. 

To further clarify:

Users "bill.palos@sun.com" and "sun.bill.palos" both exist, both have the same
email address (which isn't supposed to happen, afaik), and are thoroughly
confused wrt who has the entitlements.

(Almost) all Sun accounts that are under the group umbrella are of the form
"sun.foo.bar".  Mine (bjblack) and a small smattering of others are
grandfathered exceptions.  I'd frankly rather see "bill.palos@sun.com" go away,
with it's resources transferred to the group account so we can disambiguate. 
That alone might make this whole problem go away.

Even so, this doesn't explain why systems registered with "sun.bill.palos" show
in the group account, but not under his.  If this bug doesn't go away, what to do...

It's not a bug, it's a feature :).

The sun.bill.palos account is not an Org Admin (like say, the nspollack account
is) therefore that account only has visibility to systems that are in Groups to
which that account is an administrator. Org Admins have visibility to all
systems. The intent is to allow controlled delegation of management
capabilities. You can see which users are Org Admins and which are not at:

https://rhn.redhat.com/network/users/index.pxt

Depending on your goals you may wish to make all your users Org Admins or you
may wish to create groups and assign systems to groups and give users the
ability to manage groups. For example, you can alter the users who can manage
the "Test Group" group at (assuming you're an org admin):

https://rhn.redhat.com/network/systems/groups/admin_list.pxt?sgid=3874722

As far as having access to systems you register, Activiation Keys allow systems
to be subscribed to channels and included in groups at registration. So if you
have users who are administrators for particular system groups and you want them
to be able to register systems directly to that group, you create an activation
key and use "rhnreg_ks" to register the system:

https://rhn.redhat.com/help/enterprise/sm-systems.html#SM-SYSTEMS-ACTIVATION-KEYS

https://rhn.redhat.com/help/enterprise/up2date-actkeys.html

Closing bug, assuming Sun has the info they need now.  Reopen if that's not the
case.