You’re offline. This is a read only version of the page.
Our experience is similar to the "Running Application Server without being logged in" poster's, but with a small wrinkle. We have a VM workstation running the SL 2011 FP1 client, Application Server in that client session, and Outlook 2010. Most jobs submitted to AS are Transaction Import of journal batches to Journal Transactions. All are submitted by SSIS packages that are initiated by external events (a new extract file on an FTP site, etc.) When an RDP session is open to that App Server workstation, jobs run without flaw. If the RDP session is not running on a workstation, the process does not launch Journal Transactions processing of the batch. The App Server request is acknowledged and in the queue for processing. Journal Transactions is opened, but does not process the batch. Once a connection is made to the RDP session, processing continues to completion.
It has been suggested that a refresh of the App Server workstation via a screen macro utility would resolve this issue. It that the only road to resolution of this problem?
Thanks,
Dean Athans
*This post is locked for comments
After being educated regarding VMWare's impact on the OS (not a factor with respect to the behavior we have been experiencing), I searched for different means to disconnecting the RDP session. It appears, from my initial testing, that the Terminal Services Connection utility, tscon.exe, provides a solution to the problem. From others' recommendations we crafted a batch file that will close the RDP session and then take the machine's logged on user to the console.
@%windir%\\System32\tscon.exe 0 /dest:console
@%windir%\\System32\tscon.exe 1 /dest:console
@%windir%\\System32\tscon.exe 2 /dest:console
This accommodates the User ID being 0, 1, or 2. Run this, click OK to dismiss the warning that your RDP session is closing, and the console is open for business. A new email request gets processed, as the console is not locked.
Application Server runs in the disconnected RDP session, as evidenced by it having queued the job and opening TI. The acknowledgement message indicating the request has been submitted successfully is sent/received.
We disconnect either by clicking the RDP session Window's close (X) button, or, in the session, open Task Manager, select the session on the Users tab, right-click and select Disconnect. Sorry, but I do not follow the part about "click under processes on Application Server."
This has not been reproduced when the Application Server runs on a physical machine. If disconnecting from an RDP session locks the console of a VM guest, as has been suggested, then I should press our infrastructure team to look at the configuration of the VM host that houses this system.
I have a client using VMware right now and don't have that sort of behavior, so I don't think its VM. Dumb question: You do have Application Server running in the disconnected RDP session, meaning sl logged in and click under processes on Application Server then you disconnect the RDP session selecting Disconnect...
The RDP sessions are not timing out. After disconnecting, the behavior can occur immediately. Disconnecting appears to be the trigger for this behavior.
The workstation does not have Terminal Services configured, but uses Remote Desktop Hosting. None of the settings for the computer or any user, in Local Group Policy Editor, are set to limit the time that a session will remain open. Unless there is a known undocumented behavior on VMWare guests using this, it appears that it is properly configured.
The Local Security Policy "Microsoft network server: Amount of idle time required before suspending session" is set to 99999 minutes.
Your Terminal Service session may be timing out. You would need to turn off the time out on that server for terminal server. See this: technet.microsoft.com/.../cc758177(v=WS.10).aspx
Meaning bottom line that a session has to be running for Application Server to work. Either directly on the machine or a TS session.
Another posting to this forum mentioned an issue with the VMWare settings that might impact us. They quote the AS User Guide, page 36: "For security reasons, consider locking the console of the computer you have set up to process Application Server requests. Since the Application Server needs to be running to process most requests, locking its console will help ensure that unwelcome access does not occur. The Application Server console must be unlocked only to process Transaction Import requests."
So, if you are not using AS for Transaction Import, the issue of locking the console, which may happen due to the VM guest settings, would not exhibit any adverse effects. I am trying to get our engineering team to look at this question.
Hmm. I have here a basic (non-admin) user logged into the server with SL (2011 SP1) and the AS open and running and then I just disconnect the session and it runs fine. I didn't do anything special to get it running so I'm not sure of what to recommend beyond that.
The AS workstation machine is running on Windows 2008R2 Server 64-bit.
If you do the same thing on a server O/S rather than a workstation O/S, you should get it working like you want it to.
Stay up to date on forum activity by subscribing. You can also customize your in-app and email Notification settings across all subscriptions.
#1
André Arnaud de Cal...
291,240
Super User 2024 Season 2
#2
Martin Dráb
230,149
Most Valuable Professional
#3
nmaenpaa
101,156
Share
Report
All responses (
Answers (