Kim tae jung, All on voice portal.

Mstsc
Updated: September 28, 2007

Creates connections to terminal servers or other remote computers, edits an existing Remote Desktop Connection (.rdp) configuration file, and migrates legacy connection files that were created with Client Connection Manager to new .rdp connection files.

mstsc.exe [<Connection File>] [/v:<Server>[:<Port>]] [/admin] [/f] [/w:<Width> /h:<Height>] [/public] [/span]

mstsc.exe /edit <Connection File>

mstsc.exe /migrate

http://ms-os.com/windows-nt-server/214349-differance-between-mstsc-console-and-mstsc-session.html

When you connect to the /console session, you will take over the console
session. Meaning, you could log into the physical console of the server and see the same thing you saw remotely - you could leave something running and it would still be there when you connected from the other means.

This may help: http://support.microsoft.com/kb/278845

mstsc /console is generally used for administrative purposes.

Here are some links that you might find useful
1. http://support.microsoft.com/kb/278845

2. http://technet.microsoft.com/en-us/l.../cc740144.aspx

Documented here:

947723 - Changes to remote administration in Windows Server 2008
http://support.microsoft.com/?kbid=947723

Tip: start a command window and type mstsc /? to see which flag is
valid for your version of the rdp client.

By default, only user accounts that are part of administrators group have access to 'console' sessions. The following connections/winstations settings are not available in 'console' sessions (please refer to tscc.msc for win2k3 and earlier or tsconfig.msc for win2k8 and later):

Environment
General
Logon
NetworkAdapter
Sessions
Client

Also disable/enable/rename the 'console' connections/winstations are not
supported.

http://gogh914.tistory.com/64

HttpSession 클래스에 알아보기 전에 우선 Session이란 개념부터 설명해야 겠다. Session이란 어떤 중요한 동작이 진행중에 있는 상태를 나타낸다
고 생각하면 좋겠다. 그러니까, HTTP에 대한 어떤 연속된 관찰이라고 이해할 수 있다. 그런데, 왜 HTTP에 이런 연속된 관찰같은 개념이 필요한 것일까? 여기에는 이유가 있다. HTTP의 특성상 연속된 연결은 존재할 수 없다. HTTP는 한 번 웹서버에 접속했다가 데이터로딩이 끝나면 곧바로 연결을 끊어버린다. 즉, 연속성이 없는 것이다. 이런 개념은 부족한 network bandwidth를 효율적으로 사용하는 길이지만 웹비비에스등의 서비스에서의 사용자체크같은 문제를 야기시키게 된다.

물론, 앞서 배운 Cookie를 사용하면 사용자인증을 그럴듯하게 만들 수 있지만 Cookie를 이용한 이용자인증은 관리의 책임이 모두 프로그래머에게 떠넘겨진다는 한계 때문에 완벽한 대응책은 되질 못했다. 그래서, Servlet에서는 HttpSession이라는 개념으로 이런 한계를 뛰어넘는데 Servlet에서는 다음과 같은 개념을 사용한다. 즉, 하나의 사용자는 언제나 같은 컴퓨터에서 접속을 해온다는 사실을 이용한 것이다. 사용자는 여러 컴퓨터를 돌아가면서 같은 싸이트에 접속하지는 않기 때문에 서비스를 제공하는 측에서는 접속자의 정보를 체크해서 동일한 접속클라이언트인지 아닌지를 체크할 수 있다. 접속자의 정보로는 Cookie를 사용한다. 이렇게 함으로써 Cookie를 직접 이용하는 것 보다 더 효과적인 Client관리가 이루어질 수 있다.

http://gogh914.tistory.com/64

HttpSession객체를 얻으려면 HttpServletRequest 객체의 getSession(boolean) 메소드를 사용한다는 사실을 알 수 있다. 여기서 인자로 주는 boolean 값은 Session을 새로 만들건지 아닌지를 결정한다. true 일때는 기존에 존재하는 Session을 지우고 새로운 Session을 만들라는 뜻이며, false는 유지되고 있는 Session을 그대로 사용하겠다는 의미이다. 맨 처음 접속했을때는 HttpSession이 없는 상태이므로 보통 true를 넣어서 많이 쓴다. 이미 HttpSession이 존재하는 경우에는 true값을 넣었더라도 기존 HttpSession객체를 돌려준다. 새로 만든 것인지 아닌지는 isNew()메소드를 통해서 확인할 수 있다. 그렇다면 false는 어떨 때 쓰는걸까? 사실,
Session은 30분마다 자동으로 갱신된다. 즉, 이미 Session이 만들어져서 관리되고 있다고 하더라도 30분 이내에 다른 접속을 해오지 않으면 또다른 Session이 만들어진다는 뜻이다. 이렇게 되더라도 기존의 Session은 그대로 남게 되는데, 이때 getSession(false)를 이용한다. 자동갱신되는 시간은 자바웹서버에서는 세팅할 수 있지만, JSDK 2.0에서는 세팅을 할 수 없다. 이렇게 얻은 HttpSession객체를 가지고 할 수 있는 일이 많이 있다. 우선 HttpSession이 언제 만들어졌는지도 알 수 있고 HttpSession에 있는 Properties객체를 이용해서 정보를 저장시킬 수도 있다. 예를 들어 어떤 클라이언트가 서버에 접근한 카운터를 알고 싶다면 Client의 접근이 있을때마다 HttpSession 내부에 관리되고 있는 Properties 객체에 저장시키면 일은 간단하다. 이 Properties 객체에는 처음에는 아무것도 저장되어 있지 않다. 프로그래머의 편의를 위해서 만들어 놓은 객체이기 때문이다. 그래서 이 소스에서는 우선 "counter"라는 이름을 먼저 설정해둔다. HttpSession객체를 얻어와서 맨 먼저 "counter"의 값을 조사해보고 값이 없으면 putValue("counter", new Integer(1)) 으로 세팅해둔다. 값이 있으면 이 값을 하나 증가시켜서 사용하면 된다. 이 값은 HttpSession이 유지되는 동안에는 계속 사용할 수 있으므로 다른 용도로 얼마든지 사용가능하다. 그리고, HttpSession객체에는 HttpSessionContext객체가 포함되어 있어서 모든 HttpSession객체가 이 객체를 사용하는데, HttpSessionContext객체를 이용해서 다른 HttpSessoin은 어떤 것들이 있는지도 체크할 수 있다.

HttpSession으로는 접속되어온 클라이언트의 정보를 알 수는 없지만, 이 역시 HttpSession의 Properties객체로 정보를 넣어두면 다른 HttpSession에서 사용할 수 있으므로 가능한 일이다.

Although the data that was explicitly associated with a session is the part you care most about, there are some other pieces of information that are sometimes useful as well.

    * getId. This method returns the unique identifier generated for each session. It is sometimes used as the key name when there is only a single value associated with a session, or when logging information about previous sessions.
    * isNew. This returns true if the client (browser) has never seen the session, usually because it was just created rather than being referenced by an incoming client request. It returns false for preexisting sessions.
    * getCreationTime. This returns the time, in milliseconds since the epoch, at which the session was made. To get a value useful for printing out, pass the value to the Date constructor or the setTimeInMillis method of GregorianCalendar.
    * getLastAccessedTime. This returns the time, in milliseconds since the epoch, at which the session was last sent from the client.
    * getMaxInactiveInterval. This returns the amount of time, in seconds, that a session should go without access before being automatically invalidated. A negative value indicates that the session should never timeout.

package hall;

import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;
import java.net.*;
import java.util.*;

/** Simple example of session tracking. See the shopping
 *  cart example for a more detailed one.
 *  <P>
 *  Part of tutorial on servlets and JSP that appears at
 *  http://www.apl.jhu.edu/~hall/java/Servlet-Tutorial/
 *  1999 Marty Hall; may be freely used or adapted.
 */

public class ShowSession extends HttpServlet {
  public void doGet(HttpServletRequest request,
                    HttpServletResponse response)
      throws ServletException, IOException {
     Integer accessCount = new Integer(0);
    HttpSession session = req.getSession(true);
    String heading=null;
    if(session.isNew()){
        heading="Welcome, Newcomer";
    }else{
        heading = "Welcome back";
        Integer oldAccessCount = (Integer)session.getAttribute("accessCount");
         if (oldAccessCount != null) {
            accessCount =
              new Integer(oldAccessCount.intValue() + 1);
          }
    }
    session.setAttribute("accessCount", accessCount);
    PrintWriter out;
    res.setContentType("text/html; charset=EUC-KR");
        out = res.getWriter ();     
        out.println("<html>");
        out.println("<head><title>Request 정보 출력 Servlet</title></head>");
        out.println("<body>");
        out.println("<h1>요청 정보 출력</h1>");
        out.println("<pre>");

        out.println("----- Session Information ----------");
        out.println("Session ID : " + session.getId());
        out.println("Creation Time : " + new Date(session.getCreationTime()));
        out.println("Time of Last Access : " + new Date(session.getLastAccessedTime()));
        out.println("Number of Previous Accesses : " + accessCount);
        out.println("</pre>");
        out.println("</body></html>");

  }

  public void doPost(HttpServletRequest request,
                     HttpServletResponse response)
      throws ServletException, IOException {
    doGet(request, response);
  }
}

여기 지대로 설명이 되어 있네요. 조금 읽다가 말았는데. 지금 다른 일이 생겨서 일단 링크만 해둡니다.

http://blogs.technet.com/askperf/archive/2007/07/24/sessions-desktops-and-windows-stations.aspx

다음 날 읽으면서 정리를...

그런데 이거 한두번 읽고는 이해가 잘 안가네요^^ 여러번 읽어야 할 것 같습니다.

간단히 mstsc만 공부하려고 했는데... 점점 깊게 들어가네요.

이해가 가는 부분만 먼저 정리를 해야겠습니다.

몇 번 읽었는데 저는 쉽게 이해가 가지 않습니다.

Sessions, Desktops and Windows Stations

제가 생각하고 있는 desktop과 windows가 잘못된건지... 하핫 이해하기가 어렵네요^0^

Winlogon이 저에게는 생소한 단어라... Wikipedia에서 찾아봤습니다.

Winlogon을 이해하니까 위 설명이 조금 더 쉬워지네요. 먼저 Winlogon에 대해서 읽어보시는 것도 위 글을 이해하는데 도움이 많이 될 것 같습니다.

벌써 시간이... 곧 있으면 차가 끊길지도 ㅠㅜ

집에서 샤워하고 마저 정리 해야겠네요.

으~ 밑에 내용이 궁금해지는 군요.

So now let's dig a little deeper using an example.  In the diagram below, we are looking at Session 0 with a user logged in named Bob.  As you can see, Winsta0 contains both processes from the user console session as well as any service that is marked as Interactive.  In this case, that includes Winlogon.exe, Explorer.exe and others that need to interact with the user.  The Service-0x0-3e7$ windows station owns any service that loads under Local System and is non-interactive.  In this case I have shown Services.exe.  As you can see by the connecting bars, it is possible for processes from different virtual sessions to load into a single windows station.  The SQL process loads under its own windows station and credentials, so it is not included in either of the other windows stations.

 

 

So, to reiterate what is going on in the diagram above:

The whole diagram is Session 0.
Processes that start under the Bob account all load in Winsta0.
Interactive processes that start under Local System load in Winsta0
Non-interactive processes that start under Local System load in the Service-0x0-3e7% windows station
Processes that start under their own credentials start in their own windows station (like SQL)

그림과 함께 설명을 해주니까 이해하기가 더 쉽네요.

하지만 아직 확실히 이해를 한 것은 아니기 때문에, 몇 번 더 읽어보고 정리를 해야 할 것 같습니다.

아우... 또 읽었는데도 어렵네요 ㅎ

Tomcat provides space for a webapp's use via the context attribute
javax.servlet.context.tempdir; this normally points to the directory
work/Catalina/localhost/[appname], which is the one getting deleted.  I
suspect your webapp is taking the value of that attribute, using it for
a bit, and then erroneously thinking it should clean up by deleting it.

As an experiment, you can configure the name of the webapp's tempdir via
the <Context> attribute workDir; Tomcat creates this directory during
deployment of the webapp, but otherwise doesn't seem to touch it.
Setting the workDir attribute to some other location might solve your
problem, although the real fix is to have your webapp stop deleting
things it didn't create.

Don't change the workDir attribute for the <Host> - let that one stay as
the default.  The idea is to give the webapp a different work directory
than the one Tomcat uses.  You need to change just the workDir attribute
for the webapp, inside its <Context> element.

Where do I find the <Context> element related to axis2 (which  
> is a servlet)?

First you said axis2 is a webapp, now you say it's a servlet; I suspect
the former is correct.  A webapp can utilize many servlets, which I
think is the case here.

> Should it be inside $CATALINA_HOME/webapps/axis2/WEB-INF/web.xml?

No, the contents of that file are defined by the servlet spec (JSR-154),
whereas the <Context> element is specific to Tomcat.  It can be in
webapps/axis2/META-INF/context.xml or in
conf/Catalina/localhost/axis2.xml; the latter overrides the former if
it's in both places.  (It can also be in server.xml, but that location
should not be used for recent versions of Tomcat.)  It may not exist at
all, in which case you'll need to create it in one of the above
locations, with just the workDir attribute.

The relevant doc is here:
http://tomcat.apache.org/tomcat-6.0-doc/config/context.html

You're right; I thought I had checked that Tomcat would still use the
<Host> workDir for SESSIONS.ser, but further testing shows that's not
true.

Something else to try is configuring a nested <Manager> element inside
the axis2 <Context>, and specifying the pathname attribute as an
absolute path to where SESSIONS.ser should be stored, while having some
alternate location for the axis2 <Context> workDir attribute.  The
pathname attribute should include the file name (SESSIONS.ser), and
every component of the path must already exist prior to Tomcat shutdown.
In your situation, you could try the pathname value:
/home/nmm42/devel/tomcat/apache-tomcat-6.0.13/work/Catalina/localhost/ax
is2/SESSIONS.ser

However, you really should search the webapp source code for references
to javax.servlet.context.tempdir, and fix the code that's removing that
directory.  Deletion of the workDir affects not only session
persistence, but also trashes class files generated from JSPs.

Looks a lot like an Axis problem after all:
https://issues.apache.org/jira/browse/AXIS2-3052
"Undeploy fails to persist sessions on Tomcat 5.5 and 6"

The serialised session files are kept in the temp folder so starting tomcat
with tomcat.work.dir=NewFolderThatWontBeDeleted will solve the problem
e.g. assume for the moment you have a perm folder assigned to you called
/usr/local/michele
%CATALINA_HOME%/bin/java -Dtomcat.work.dir=/usr/local/michele bootstrap.jar