Hi Chris,
Error of unloading user hive is fine - basically it tells you that most likely hive is in use (eg. user logged in etc.) and hive cannot be unloaded at the time. If hive could not be loaded then I'd start worrying because that would mean that SUM cannot capture data for that user.
Long time issue. Is it possible for you to email me that template and logs? I am suspecting that even though package is not that huge, you are specifying too many inclusion files to check and this might cause delay. SUM capture files/folders works as follows:
SUM gets all inclusion paths for each user and merges them all into one list. Where paths equate they get combined into one path. Basically from a long list of paths and extensions, you get much shorter list of unique paths with potentially bunch of extensions. For instance you set 3 paths: c:\*.txt, *.mp3, *.doc. They get combined into two paths:
1. c:\ with single extension *.txt
2. $LocalDrives$ with two extensions *.mp3 and *.doc
This logic is done so that SUM doesnt have to process same path multiple times not just for a single user but potentially for multiple users as well.
As you can see from above example to process this list would still requires to search your entire c:\ drive at least twice: once for *.txt and second pass for *.mp3 and *.doc. You can optimise it by specifying c:\*.mp3 and c:\*.doc instead of giving them no drive.
In general simple search of your hard drive for any given file extension using Windows Explorer takes long time as well and SUM is no exception - the more stuff you want to search on, the longer it takes. You'll need to narrow the search down.
Of course your issue might be completely different but my comments above might still help people to understand how engine works and optimise path search appropriately.