Removing Trusteer Rapport

After uninstalling Rapport, some folders will remain, storing your Rapport settings (for future installation) and Rapport logs (for technical support analysis, if needed). These files and folders are completely inactive and may contain information useful for future installation or diagnosis of problems with Rapport.
Should you choose to delete these folders, or if you have trouble uninstalling Rapport and would like to manually remove all folders, please follow the instructions provided below. 

Removing Rapport folders for Mac OS X

Removing Rapport folders for Windows XP

Removing Rapport folders for Windows Vista / 7 / 8

1) Go to Start menu and Choose Run (or Press the Windows key and the 'R' key together)
2) Type "C:\Program files" (or "c:\program files (x86)" for 64-bit machines) and click "Ok".

3) Find a folder named “Trusteer”, right click it with the mouse, and choose “Delete”. Make sure the folder was removed.

4) Open the Run command as described in step 1
5) Type "%userprofile%\appdata\local" and click "Ok".
   
6) Find a folder named “Trusteer”, right click it with the mouse, and choose “Delete”. Make sure the folder was removed.
* If the path results in an error, please use the following path instead: %appdata%
7) Open the run command again and this time type "%programdata%" and click "Ok".

- If you cannot locate the folder, it might be hidden because of default settings. 

To change the folder’s settings: 

- Go to the Start menu, 

- Click on Control Panel, 

- Click on Folder Options, 

- Click on the View tab, 

- Under “Hidden files and folders”, choose “Show hidden files, folders, and drives” and click OK. 

 

8) Find a folder named “Trusteer”, right click it with the mouse, and choose “Delete”. Make sure the folder was removed.

9) Open the run command and this time type: c:\windows\system32\drivers. Click Ok.
10) Locate the following files and remove them (right click it with the mouse, and choose “Delete”):
* RapportKELL.sys (would be named RapportKE64.sys in 64-bit operating systems)
* RapportHades64.sys (Windows 8 only)

11) To ensure all Trusteer files were removed, open C drive and search for “Trusteer” in the search bar on the top right-hand side of the window. 

If any files related to Trusteer are found, delete them. 

AppV Application Slow to open

I've recently sequenced a Pathology application that we use in the NHS that uses a Terminal Emulator to retrieve bloods direct from the Lab.

I had managed to sequence it fine but the package was taking an age to load up and sometimes timing out completely.

After looking at the SFTLOG (C:\ProgramData\Microsoft\Application Virtualization Client) I noticed an error: 4636126-0B01FD04-0000041E

As per AppV error format:

App-V Error 04-0000041E

Event:
Starting/Running the application
Error Message / Symptoms:
It took to long until the application was ready for interaction with the users.
The application shuts down after about 5 minutes
Potential Causes:
The application is a Java or DOS like application. App-V can not determine that the application is ready for User Input, because the app does not use default Windows Classes.
Potential Solutions:
In the OSD file, SUBSYSTEM VALUE has to be changed from "windows" to "console" (case sensitive).
If it is an 16-bit application, also the VM VALUE should be set from "Win32" to "Win16"
References:
Microsoft Knowledgebase Article: http://support.microsoft.com/kb/931112. This articles lists a set of potential causes, however the most common reason (SUBSYSTEM "windows") is not listed there.

Thanks to Falko at  Kirx.org for the above.

Once I'd made these changes I updated the package and viola, Bob's your aunties live-in lover!

SCCM Collections not updating - eggtimer displays

I've had a problem with the old girl recently - our SCCM 2007 environment had been chugging along nicely until a few weeks ago.

We have approx. 500 collections with update schedules running pretty evenly throughout the day.  As I'm sure you will agree the annoyance of the the old Update Collection Membership and then refresh the console is a blight on our day - but when that little red eggtimer WILL NOT DISAPPEAR it sends my SCCM OCD twitching and I just cannot carry on with my day until I've sorted it...

 

I've done a fair bit of Googling and not really found that many comprehensive solutions to this other than those that point to the Microsoft KB982400.  I was checking the Colleval.log and kept seeing Checking collection: 0x18, EvaluationCRCChanged=FALSE, ScheduleCRCChanged=FALSE, AwaitingRefresh=TRUE - which is fine, yes it's awaiting a refresh - SO REFRESH ALREADY!!!!

The D:\PROGRAM FILES\MICROSOFT CONFIGURATION MANAGER\inboxes\COLLEVAL.box seemed fine and the BADRELP and RETRY folders were empty - so what was causing this???

Finally I spotted a few references to AV related issues (which I suspected were responsible for another issue I have with slow PXE boots).  Sure enough, when I killed off all the Trend related services from Windows Task Manager and did another update and refresh of the collection - IT WORKED!!

Trend Services Running on the SCCM Server

I've since added an exception to Trend File scanning for the PROGRAM FILES\MICROSOFT CONFIGURATION MANAGER\inboxes folder and I've noticed a considerable improvement - I'll post back after a week or so to let you know how it's going.

Hope this helps someone else...

DocN

***UPDATE***

It seems the actual problem here was down to the sheer volume of collections running updates.  There was a cumulative effect of the schedules and come 1pm the collection action list was backed up with about 3 hours of updates pending.

I've gone through and removed all update schedules from our collections (yes - it was a lengthy monotonous task) and all is well.