ABOUT IK

IK, short for Inverse Kinematics, is the way to go to animate characters. It lacks some of the control provided by Forward Kinematics solutions, but it's much faster to use and has some great advantages over FK. One of the most important is that, since the IK solver is an object outside of the hierarchy, it can be used to anchor the IK-driven chain to another object. Imagine you needed to animate a character doing pushups... doing so with FK could turn into a nightmare, because the main animation would come from rotation the spine and hips, and keeping the feet and hands at the exact same spot in the floor throughout the whole animation. Most people did this in the past using a pen marker to mark on their monitors where the hands and feet were located, and rotating them using FK every keyframe (not every frame! although it could happen...). And even if you were extremely careful, some sliding was sometimes unavoidable.
However, with IK, since the solvers are at a different place in the hierarchy, they'd take care of keeping the whole chain positioned at the exact same spot (for as long as you didn't move the solvers from their place). That made life a WHOLE LOT easier for animatiors.
So, those are some of the differences of IK and FK. If you need more info on this subject, please read my FK/IK paper located at the papers section of my site. Hope all is clear. So, let's move on...

APPLYING IK SOLVERS

Ok... we're gonna need four IK solvers here... one for each arm, and one for each leg. Let's ge one thing straight from the beginning... you DO NOT use IK to animate fingers or necks/spines. I can think of a couple of situations where I can think of using IK for fingers, but these are extremely rare and IK should NOT be incorporated into standard rigs at these areas. Anyway, here goes...
Select the root bone for the arm chain (Bone_armRT in the case of the right arm). Go to the animation menu, and select IK solvers/ HI Solver. This is the history independent solver, and it's the one you should use on every character you build. The HD Solver is the one we had in max 3, and it's useful if you require sliding joints, so it's more used for mechanical rigs. The Limb Solver is a "limited" version of the HI solver (it only supports 1-joint chains), and, if you're using max5, we've got the all brand new SplineIK Solver... we'll use that one on the advanced tutorial.
One you've selected the HI Solver, you'll notice a dashed line appearing in your viewport that follows your mouse. It's part of the solver creation. It needs a second node to tell where the solver will end. All nodes included in an IK solution MUST be part of the same hierarchy. You may not use different hierarchies under the same IK solver.
So, go ahead and select the arm chain's nub bone (Bone_armTermRT, in the case of the right arm). Once you did, a blue cross will appear at the nub bone's location. This is what's called the goal. The IK solution will always try to solve rotations to aim at this goal. So, whereever the goal goes, the chain will follow... go ahead, try moving the goal and see how an IK-driven chain behaves...
Once you go this one, go ahead an add solvers to the rest of the chains (arms and legs). The leg's chains go from the root of the legs to their nub bones (in the case of the right leg, it goes from Bone_legRT to Bone_legTermRT).
NOTE: Make sure each IK chain is set to Start Joint Parent Space. You can check this by selecting the IK chain's goal and going to the motion panel.

This is what you should end up with...

Ok. We've got IK solvers on out character. However, we'll need some extra controls to help us animate the character properly and in a easier fashion.

ARM CONTROLS

We'll need some controls to help us animate the arms and hands properly. I'll just go through the process for one arm, and you can do the other arm when you're done.
First, lets create a point helper, and align its position to the nub bone's pivot point (or you can use the IL's goal, if you haven't moved it). Once it's there, link the IK chain's goal to this point helper. Set the point's display properties to show the box only, and size it to your liking. Name it ArmControlRT (or LT, if you're working on the left arm... you already got the whole suffix idea, right?). Try moving it and the whole arm should move...

Now, create another point object, and align it to the nub bone again, but this time align both its position AND orientation. Set the display properties to show the Axis tripod only. Size it so it's easily selectable. Now, link it to the arms forearm bone (Bone_forearmRT). Now, link every bone in the hand chains to this helper (these would be the bones that were created by connecting the fingers to the nub, remember?). Here are the bones you should link to this helper...

Once they're linked, select again the helper you just created and name it HandControlRT. Go to the Link Info section if the HIerarchy panel, and turn off ALL the rotation Inherit switches. This will keep the hand locked to "world space" instead of "local space". It means it will prevent sliding and rotating when the hand should be locked to the world. The downside is you'll need to animate the rotations whenever the character moves its arm so the hand keeps with it, but it's just a minor issued compared to keeping the hand locked to other objects.

Now, create another point object, and align it to the shoulder (Bone_armRT). Move it backwards to the back of the character. Name it ArmSwivel_RT, and link it to the topmost bone in the spine (Bone_spine04). This node will help us aim the elbow. Select the IK chain's goal, go to the motion panel, and in the IK solver properties rollout, click on the "Pick Target" button under IK Solver Plane, and select this point object. This will orient the chain so that the elbow faces towards this node. We linked the point object to the spine so that when the character bends his spine, the arm keeps its orientation relative to the spine. If you'd rather have the elbow's orientation locked to something else, you can link this point object to something outside the spine hierarchy, such as the COM we'll create later (I like it the way it is now).