So after 2 years this management script is still has a logic error which makes using it poitless if not saying harmful.

Major issues:

'IndexUsage' column calculated as (user_seeks+user_scans+user_lookups+user_updates) is used to decide whether we need to rebuild or drop the index.

So in case there is a totally useless index on highly active table where user_seeks+user_scans+user_lookups = 0 but user_updates is big enough then such an index would be rebuilt each and every time we run the script consuming cpu and creating extra load on I/O system. When it's obvious that such an index should be dropped as useless one.

And what is so called "Unused Indexes" are not affecting performance at all, if there are no updates on these indexes then there are no maintenance costs. The only reason you may want to drop them is because of the disk space.

Usually to find good/bad indexes one should use some kind of difference between (user_updates) and (user_seeks+user_scans+user_lookups)

Minor issues:

Limitition of Uf_GetIndexSize to only non-partitioned tables.

Reorganizing heavily used indexes every time even if they don't have fragmentation (@avg_frag<=20)

REDUILD index without ONLINE option (for enterprise edition) may lock the whole table and it is very critical for 24/7 systems

There is no deletes from tblUnusedIndexes, so I'm assuming it's a history table? If so then there is no timestamp in it. Analyzing such a mess can become a challenging task for a DBA.

Dropping index by some fake ID - @UnusedIndID is not a wise decision as well.