Monday, December 10, 2012

.NET 4 Full Install Saved The Day

Last week ended well. A remote user has been using a work app in an odd way and now she can finally use it 99% just like the users at our main site. Cool. Before, I had her connecting to our main site via Sonicwall Global VPN client, then using RDP to a virtual machine. No, it's not a horrible way to use the app, but it's not the best. Why did I have her setup this way? I'll explain.

Our application we use for HR, payroll, general ledger, project management, etc. runs from serer1. It's installed on that server. Our main site users have a mapped drive to server1 and a shortcut to the app on their desktops. They click on the shortcut, and since the app is web based, IE 8/9 pops up with the app graphic and a link for the database to connect to. Once the database link is clicked, the login window pops up for the user to put in her credentials then away she goes working. That's how the run process, well, runs. For the remote user, I had in mind the following: connect via vpn then use the app just like users at the main do. Well, my setup didn't go as planned. Earlier this year when I setup the remote user for app use, I ran the sonicwall vpn global client to connect to our main site. I mapped the drive to server1, placed the shortcut to the app on her desktop, clicked on it, ran the config, the IE app graphic window popped up, I clicked on the database link, but then nothing happened after that. Nothing. I clicked again and nothing. I at least expected an error message, but I wasn't given anything. The user was pressed for time. I asked her if I could investigate, that it could probably take a lot of time and she more or less said "no." I told her I could make a quick fix and she was fine with that. So, I setup the RDP method. She was fine with that and she had been fine with that for many months.

Last week she reminded me about it and wondered if I could eliminate the remote step. I told her it would probably take some time and she was fine with that. I setup a lab in my office, almost identical to her setup (the only difference was my connection was wireless). In my lab an error message displayed on the screen. I clicked on the database link, then BAM an error message popped up reporting an app crash. I flew to the event viewer and found an application crash reported. I then decided to compare and contrast my lab setup and our production setup. I found a difference (besides the vpn connection, :P): our production computers had .NET Framework 4 Extended and Client Profile whereas my lab computer only had .NET Framework 4 Client Profile. So, I installed .NET 4 Full on my lab computer and after that the app worked flawlessly.

I then called the remote user, setup a time, went out there installed .NET 4 full and then the app worked exactly as it should have worked. The user was ecstatic. I had never seen her so happy. She told me she didn't mind going through the RDP, but the text was small, the connection would timeout after inactivity; just those little things that don't ruin your work, but are just so annoying you can't work happily you know? Well, so far, so great for her current setup. All she has to do now is run the sonicwall global vpn client then she is able to work within the app.

Any suggestions for an alternate setup?

Wednesday, December 5, 2012

Can't Change Screen Resolution During Remote Session

A lot of screen resolution problems lately. This one though is a problem a remote user had yesterday during her remote session to a vm she logs into at our main site. Her setup is the following: vpn to our main site, rdp to virtual machine. At her remote site, the power user there installed new monitors for clients. The new monitors are wide screen monitors, replacing their old square monitors. This client in particular didn't like the new monitors because of the small display size that wide screen monitors typically default to. The power user at the site customized the user's desktop very well just by changing the display size of the screen to %135.

Yesterday, I got a call from the power user telling me the client wasn't happy with the display size for her remote session, especially since she couldn't customize the screen resolution or display size (both are grayed out during a remote session). The remote user was trashing the vpn connection, our software, and everything else that wasn't related to the actual issue. The power user said he couldn't figure out why they couldn't change the display settings. He thought it may have been a privilege issue, but that's not the reason. From what I know, display settings cannot be changed during a remote session.

To fix the issue I went to our server, logged into the virtual machine the remote users logs into and changed the display size to 150%. She was happy, the power user was happy; it was good.

There might be a workaround, but I don't know of one. I'm not far from the physical server, so the best solution for me was to go to the server and change the display size for the vm, call the power user and ask him how the new size looked.

If you know of a solution for changing the display size of a pc during a remote session comment below.

Tuesday, December 4, 2012

Screen Resolution Problem and Enlarged Text

Interesting problem yesterday. I have clients who run surveillance camera software (CMS) on their computers. The software pulls the feed from their networked dvr system. The network has mixed client hardware, i.e., each client has different monitors and a different workstation (though I've almost got each client the same workstation now), so I installed the CMS software to match the client's screen resolution choice. After setup, there have been no problems with the CMS configuration for many months.

Yesterday, I received a call from one of the clients. He told me when he clicked on the CMS icon a window appeared with a message "screen resolution must be at least 1024 x 768." I asked him to please check his resolution, walked him through that process and, no surprise, found out his monitors (he has two) both have that resolution. I'm not far from the client so I just made the walk over to his office. I checked the resolution to just knock that off my troubleshooting list and I couldn't believe that CMS still wouldn't run. I was truly bamboozled. Windows screen resolution is 1024 x 768, but CMS wouldn't run because the resolution had to at least be 1024 x 768? Confusing. It was just confusing.

He has an nvidia video card with a control panel. So, I checked that just out of curiosity and obviously the resolution there matched Windows. I checked the Windows Update history. He said CMS worked just fine Friday. Their systems do windows updates over the weekend, so I thought maybe there had been a big update or something. The only update over the weekend was an update for Windows Defender. To my knowledge, that wouldn't have anything to do with my problem. After drumming my fingers for a little bit, I decided to reinstall the software sine it's a simple install. I reinstalled the software hoping that would fix the issue. It didn't. I truly didn't know what to do. Trying not to panic, I went through my history list with this system (these are very helpful) and found that when setting up the system I enlarged the display text to the maximum size, which is 150%. I checked the text size and it was still set to 150%. I turned it down to medium 125%, logged off then logged back in and clicked on CMS. The software ran. Again, bamboozled. Since I reinstalled CMS earlier, I had to configure the software with the dvr (less than 5 minutes) and it worked just fine. I asked the client if that display size was fine and he said it looked great (though back in the day of setting up this system he liked the max size...no comment). So, I left the display size alone at 125% with the screen resolution of 1024 x 768. Which the only difference is between then and now is the display size.

What happened? I don't know. Event viewer didn't tell me anything either. My client is happy, but I'm perplexed about CMS suddenly not recognizing that Windows did have the correct resolution for the software and that the software worked fine for many months with the 150% text display.

To any readers: thoughts?