The "Product backlog Item" is indeed the What, the functionality that needs to be built. The Task describes the steps that need to be taken to get there.
Many teams are not used to decompose into tasks, they just build what the spec says. For these people it's hard to see them as two separate things.
Maybe a simple anecdote would help:
See the Product Backlog Items as the items on their shopping list for their vacation. Maybe a "tent", a "fishing rod", a "prepare car for travel".
The Tasks for the "tent" item would be "Describe tent requirements", "Compare tents online", "Get advice from friends with outdoor experience", "Go to outdoor shop", "Buy tent", "setup tent in backyard to verify completeness", "pack tent for travel"
The Tasks for Fishing Rod will be very similar, but the tasks for "prepare car for travel" are probably very different: "Check requirements for states/countries on desired route", "buy safety vest", "replace expired contents from first aid kit", "inspect spare tire", "schedule appointment with garage to have engine checked", "go to garage to have engine checked", "go to state agency to buy highway pass", "check car insurance"
This clearly separates the question of what the product owner wants from what they need to do. Unless of course the product owner already decomposed into actionable items on the Product Backlog, in which case you also need to talk to them.
As I said, for many developers they think they already have enough information and know what to do, they don't want to decompose the What into How steps, they'll get there when they get there. When you start talking to them about tracking the sprint progress, improving estimations, tracking work that was forgotten during sprint planning and other items that have to do with professional improvements, ask them how they and their team will know where they can improve and how they know they're really done. When they can come up with a system that works without creating tasks and it works, then that's fine, but chances are very low that they actually can.
Before trying to work with TFS and the agile tools, your team will need to understand how this all works. The best way is to have them work with a paper board, which is visible on the work floor to all. Later, when the process is understood better, moving to the tools will help. Without the understanding, the tools won't be of much use and will meet a lot of resistance.