The difference between anemic domain model and an entity

I am trying to get a firm understanding of DDD and having read Eric Evans book on Domain Driven Design and blogs from Julie Lerman they describe:

Anemic Domain Model as a model with classes focused on state management. Good for CRUD.

Entity as a mutable class with an identity used for tracking and persistence.

Surely both are used for the same purpose or I have completely got the wrong end of the stick? What is the difference between the two? I have read that an anemic domain model is often used to represent a database schema, but isn't the same for an entity too?

For example, a table called Customer which has:

CustomerId int
Forename varchar(50)
Surname varchar(50)
IsActive bit

From my understanding an anemic domain model to represent this would look like:

public class Customer
{
  public int CustomerId { get; set; }
  public string Forename { get; set; }
  public string Surname { get; set; }
}

Past experiences for me suggest that an entity would also be represented in this fashion with a series of getter and setter properties, a la Entity Framework? Both concepts (entity and an anemic domain model) are mutable?

Thanks, DS.

A DDD Customer entity might have Customer::changeName(Forename,Surname)...;

changeName would only be triggered if the customer is actually changing their name. You would then embed whatever business logic is necessary for dealing with a new name. Perhaps there are pending orders with the old name. Maybe you want to update them to the new name. Maybe not. Lot's of possibilities.

For me at least the basic difference between a anemic domain object and a DDD entity is that the entity is going to actually do something more than just update properties.