Installing Logmein When a Console Session Isn’t Available

At my company, we use LogMeIn to provide remote support to our client base. It’s an incredible tool.

However, when installing LogMeIn, it doesn’t work to install thru an RDP session. What happens is that LMI binds to that session rather than to the console and once you logout, there’s nothing left to connect to and you get that black box error about Terminal Server problems.

Here’s the workaround – We’re going to install a VNC server on our target and the VNC viewer on the workstation we’re on. Then when we make the connection via VNC, we’ll be connecting to the console of the server rather than the RDP session we’re using to get there and will be able to install LogMeIn properly.

• Connect to a machine on the network. This should not be the target server we’re trying to install LMI on. It can be a workstation or another server. We’ll call this the host machine.
• RDP to the server you want to add to LogMeIn. We’ll call this the target server.
• Download TightVNC here – www.tightvnc.com
• On the target server, install TightVNC with both the server and viewer components. Make sure you set the passwords during the install process, otherwise it won’t work.

 

 

 

• On the host machine, install the viewer only.
• Once you have the viewer installed on the host, run the viewer client. Choose Listening Mode on the right side.

 

 

• The connection screen will disappear and will minimize to an icon in the system tray.
• On the target server, you should also have an icon in the system tray. Right click and choose Add Listening Viewer
• As a target, enter the host machine’s name or IP address.
• You should now have a window pop-up on the host machine with a view of the Console of the target server.
• You can now login and install LMI.
• After you’re done, close the VNC window. Stop the service on the host machine by right clicking on the icon in the system tray and choosing Close Listening daemon. Uninstall TightVNC from the host machine.
• Next, stop the service on the target server and uninstall TightVNC from that machine as well.

Returning Waiting Workflows in CRM

Our CRM system seems to have slowed over time. One of the reasons is an increase in the number of workflows that are in a waiting state.

I have a SQL script that I ran against the company_MSCRM database to return a list of all the workflow names that were in the wait state, exported the list to Excel and subtotaled it to get a unique count for the number of each workflow. Sort by count and you get a good list of where you need to start optimizing workflows to hit and stop rather than wait for something to happen.

In our case, the number 1 culprit was a workflow that waits for the regarding attribute to be set to an account rather than a case. As a service organization, we try to push all of our service work thru cases. Instead of doing a check and then existing, the workflow ‘waits’ for the regarding to equal an account. This means that every open activity in CRM has a live workflow waiting for the regarding to equal an account.

Here’s the SQL script I used to return the waiting workflow names.

Select asyncoperation.Name
from asyncoperation
where StateCode = 1
    and RecurrenceStartTime is null
    and DeletionStateCode = 0
ORDER BY asyncoperation.Name

This code is based on an article by JonSCRM on MSDN.