...
With IIS, the first thing to do is to check the Windows Event Log. If you access a site with the filter installed, you should get event log messages saying that the filter initialized. If so, the filter is running, and there's a decent chance permissions are OK. If not, start by making sure that the anonymous IIS user (IUSR_<machine>) has read access the \opt\shibboleth-sp tree. There may be other accounts that need access if you have ASP.NET AppPool identities configured.
You should also make sure those accounts can write to the \opt\shibboleth-sp\var\log\shibboleth folder. Otherwise you won't get a native.log file created. If that file's there, you should see additional information about the health of the filter.
Green Arrow
All those steps should lead to the wondrous "green arrow". Once you access a web page on a site with the filter installed, you should get the arrow in the IIS GUI on the Filters tab. If there's no arrow, or it's red, or Unknown status, something's not right. But that only matters if you've accessed the site. Until you do, restarting will leave the filter in an Unknown state on IIS 6+.
...
If you still have no joy, the next step is to try collecting some logging detail. You need to raise the native logging level to DEBUG by editing native.logger and changing the default INFO level to DEBUG. Then you'll want to restart IIS. You should get more verbose information in the in syslog or the Windows event log (or in older/upgraded systems, the native.log file).
It will include a line each time you access the site that tells you what URL has been "mapped" by the filter. If it doesn't look right, you should get a hint on what to fix. If you get nothing, despite raising the level to DEBUG, then the filter isn't running, or isn't configured to process requests for the affected site.
...