I need to run overnight automation testing using RFT and IE on Windows7 virtual machine. I found that restarting the Windows box before the testing starts helps.
I am moving the production environment from Windows XP to Windows 7. RFT used to complain when running RFT scripts that CRFCN0557E: Activation failed when running under a Terminal Services environment. This may be caused by using a minimized terminal window - try playing back without minimizing the terminal window (it does not need to be full-screen).
Running tscon.exe 0 /dest:console
prior starting any RFT script fix the error on Windows XP. But not on Windows7.
I did some research and was trying for hours to fix that but nothing helped. There is no screen saver turned on on Windows7.
I tried to run both but nothing helped.
tscon.exe 0 /dest:console
tscon.exe 1 /dest:console
On Windows7 tscon returns
{ErrorPrintf(): LoadString failed, Error 15105, (0x00003B01)}
Error [15105]:The resource loader cache doesn't have loaded MUI entry.
Error [0]:The operation completed successfully.
On Windows XP tscon returns
Could not connect sessionID 0 to sessionname console, Error code 7045
Error [7045]:The requested session access is denied.
I just double checked that running tscon.exe 0 /dest:console
on Windows XP solves the issue. Cannot understand the output of the tscon command then.
Any idea how I can run RFT scripts after I restart the Windows box automatically? Preferably without involving any other computer. I was even thinking to use the old Windows XP to make remote desktop session to make RFT happy. I hope there is other better solution to that.
Before I get to your primary issue I'd like to point out that the fact that you are getting the message
{ErrorPrintf(): LoadString failed, Error 15105, (0x00003B01)}
Error [15105]:The resource loader cache doesn't have loaded MUI entry.
is an indication that something has become corrupted on your system. MUI is the multilingual user interface. Is the Windows 7 computer in question set to use a language other than "English (United States)"? It looks like tscon is trying to find and display an error message in your configured language, but it can't find the language file that it should use. This may be a symptom of a larger problem. You're using tscon.exe that was installed on that computer and not one you copied from another computer, right?
You might be able to correct this problem by running sfc /scannow
after taking a snapshot and seeing if tscon gives the same error.
As for your primary issue, the number you are supplying to tscon indicates which session ID to act on. Have you checked if you are using session 0 or 1? Run query user
to see what your session ID is and then use that number.
For example, I get this output from query user
on one of my servers:
USERNAME SESSIONNAME ID STATE IDLE TIME LOGON TIME
>starfish rdp-tcp#4 2 Active . 9/20/2012 10:12 PM
Since my session ID is 2, I run tscon 2 /dest:console
to send that session to the console. When I go to the console and run query user
I see the following:
USERNAME SESSIONNAME ID STATE IDLE TIME LOGON TIME
>starfish console 2 Active . 9/20/2012 10:12 PM
I also tested this on a Windows 7 Pro desktop with the same results.
If you have success with the commands above, you can put the following into a batch file and run it to send your current session to the console.
for /f "skip=1 tokens=3 usebackq" %%s in (
`query user %username%`
) do (
%windir%\System32\tscon.exe %%s /dest:console
)
It should also eliminate the need to restart the computer, which I suspect was to make sure you always got session ID 0.
This page says the issue is with the system being locked when trying to run it through scheduled tasks: http://www-01.ibm.com/support/docview.wss?uid=swg21304791
Setup the system to automatically login, disable the screen saver and automatic locking, and see if that helps. Don't connect to the machine through remote desktop - that will lock the console session. Install vnc to login instead or use whatever method your virtual machine software provides. In fact, turn off remote desktop so you can't lock the system by accident.
To setup autologin, run "control userpasswords2"
According to this: http://support.microsoft.com/kb/302801 Tscon would actually leave the session unlocked in server 2003 (and, presumably) xp. This was a bug that has likely been corrected in newer windows versions.
User contributions licensed under CC BY-SA 3.0