기타2008. 2. 24. 20:42
그간 개인 위키를 하나 만들어야 겠다는 생각을 하다가.. 오늘 실행에 옮겨버렸다.

Cafe24 호스팅 서비스에 호스팅을 신청하고, MediaWiki를 다운받아서 설치하는 간단한 작업이었지만, 몇 가지 문제가 있었다.

1. Cafe24 리눅스 호스팅은 PHP5를 지원하지 않는다.

그래서, MediaWiki 최신 버전은 포기할 수 밖에 없었다. Cafe24 호스팅에 설치가 가능한 Media Wiki 최고 버전은 1.6 버전이다. (참고로 Media Wiki의 현재 최신 버전은 1.11이다.) 그러니 Media Wiki 다운로드 페이지에서 1.6.10 버전을 다운로드해야 한다.

사용자 삽입 이미지


2. Cafe24 Hosting 서비스 신청 시에 데이터베이스를 UTF-8로 세팅했다면, DB 테이블 생성 과정에서 아래와 같은 에러가 나게 된다.

"Specified key was too long; max key length is 1000 bytes"

이 에러는 MySQL 개발 측에서도 버그로 인지하고 있는 부분이기도 하다. 아래 링크를 보면, 꽤 오래된 이슈라는 것을 알 수 있다.

 http://bugs.mysql.com/bug.php?id=4541


이 에러를 해결하기 위해서는 소스를 조금 수정을 해야 한다. 수정해야 할 소스는 다운받은 MediaWiki소스 중에 Maintenance 폴더에 있는 tables.sql파일이다. 총 3군데를 고쳐야 한다.

Line 424
기존: cl_to varchar(255) binary NOT NULL default '',
수정: cl_to varchar(200) binary NOT NULL default '',

Line 915
기존: job_cmd varchar(255) NOT NULL default '',
수정: job_cmd varchar(100) NOT NULL default '',

Line 920
기존:  job_title varchar(255) binary NOT NULL,
수정:  job_title varchar(100) binary NOT NULL,

이렇게 수정해줘야 하는 이유는, MySQL에는 Index 칼럼에 1000byte제한이 있기 때문이다. 255면 1000이 안 되지 않느냐고 말할 수도 있겠지만, UTF-8에서는 한 자당 3byte를 소모하기 때문에, 여러개의 칼럼이 인덱스를 구성하는 위 쿼리들에서는 1000byte를 초과하게 되는 것이다. 그래서 Line 424의 쿼리에서는 200으로 수정해주면 되고, Line 915와 920의 경우 저 두 칼럼이 한 인덱스를 구성하기 때문에 100에서 150정도로 수정해줘야 하는 것이다.

위 과정을 통해서, Cafe24 호스팅에 성공적으로 Media Wiki 설치를 완료했다. 개인 위키이긴 하지만, 사적인 내용은 없고 개인적으로 공부하는 것들을 좀 정리하고자 만든 위키이니 다른 분들의 방문도 환영한다. ^^

URL은 http://kkongchi1027.cafe24.com

사용자 삽입 이미지

Posted by kkongchi
코드분석 규칙2008. 1. 19. 11:49
이 블로그에서도 간단하게나마 FxCop Custom 규칙을 만드는 방법을 "[HowTo]FxCOP(비주얼 스튜디오 2005 코드 분석) Custom 규칙 작성하기(C#)" 라는 제목으로 소개한 바 있었다. 내용이 너무 부실해서 민망하긴 해도, 아주 간단한 규칙 정도는 작성할 수 있는 수준의 글이었다.

오늘 MS의 Code Analysis Team Blog"Tutorial on writing your own Code Analysis rule" 이라는 글이 올라와서 봤더니, BinaryCoder.Net의 Jason Kresowaty라는 친구가 올린 "FxCop: Writing Your Own Custom Rules"이라는 글을 소개하는 포스팅이었다.

아직은 대충 봤는데, Introspection Object Model에 대해서 아주 자세하게 다루는 것이 눈에 띈다. Introspector라는 자기가 만든 유틸리티도 소개를 하고 있고. 찬찬이 읽어 봐야 겠다.

아래는 그 Instrospector라는 유틸리티의 스크린샷

사용자 삽입 이미지

'코드분석 규칙' 카테고리의 다른 글

[Article]Visual Studio 2005 Team System 코드 분석  (2) 2006.10.14
Posted by kkongchi
Sharepoint Portal Server2008. 1. 13. 15:15
Sharepoint Service 3.0의 백업은 Central Administration에서 이루어진다.

Central Administration에서 Operation 탭으로 가면 Backup & Restore라는 메뉴가 있다. 거기에서 Perform a Backup 링크를 클릭하면 백업할 수 있는 화면으로 가게 된다.

사용자 삽입 이미지


그러면, 백업할 수 있는 요소들의 리스트가 뜬다. 여기서 전체를 할 수도 있을 것이고, 선택적으로 할 수도 있다.

사용자 삽입 이미지


그 다음은 백업 옵션을 설정하는 화면이다. 백업 방법(Full & Differential)과 백업 디렉토리를 설정한다.

사용자 삽입 이미지


그러면 백업이 시작되는데, 이 작업은 꽤 시간이 걸리기 때문에, 바로 상태가 나타나지는 않는다. 툴바의 Refresh 버튼을 누르다보면 아래 그림과 같이 계속 상태가 업데이트되게 되는 것을 확인할 수 있을 것이다.

사용자 삽입 이미지



하지만 이렇게 Central Administration 사이트에 들어가서 수동으로 백업을 하는 것은 간편하기는 해도 꽤 귀찮은 일이다. 그래서 STSADM.EXE와 윈도우 스케줄러를 사용해서 백업을 자동화하는 것이 더욱 좋을 것이다.

TechNet사이트의 Window Sharepoint Service 3.0 Library의 "Automate the backup process by using a batch file" 이라는 문서에 자세한 방법이 나와 있는데, 그 step을 소개하자면 아래와 같다.

1. 노트패드를 열어서 아래와 같은 내용을 입력한 다음, WSSBatchBackup.bat라는 이름으로 저장한다. (C:\backup이라는 디렉토리이름은 자유롭게 바꾸면 된다)

@echo off
echo ===============================================================
echo Back up sites for the farm to C:\backup
echo ===============================================================
cd \Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN
@echo off
stsadm.exe -o backup -directory "\backup" -backupmethod full -overwrite
echo completed

2. 제어판 -> Scheduled Tasks로 이동해서, 새로운 스케줄을 만든다. 그리고 그 스케줄에서 실행할 파일을 아래 그림처럼 스텝1에서 만든 Batch파일로 지정하는 것이다. 스케줄의 실행 주기는 필요한 만큼 설정하면 된다. (내 개인적으로 매일 백업하도록 설정해 두었다.)

사용자 삽입 이미지


이와 같이 스케줄로 설정해서 자동화시켜두면, 이제 수동으로 백업할 일은 없을 것이다. 그리고 유사시에는 이 백업 파일을 활용해서 빠른 복구가 가능할 것이다.
Posted by kkongchi
Sharepoint Portal Server2008. 1. 5. 21:47
죽어버린 Sharepoint 팀 사이트를 살려라. 사건개요 보기

DB까지는 어떻게 회복을 했다. 그리고 다시 다른 서버에 Sharepoint Service 3.0을 새로 설치하고, 기존 서버를 백업한 파일을 Restore하는 방식으로 Sharepoint 서버를 옮기게 되었다.

여기서, 또 하나의 문제가 발생했다. 서버를 옮길 때에 기존에 있던 모든 계정을 똑같이 만들어줬음에도 불구하고, 기존 계정들과는 다르게 인식이 되는 것이다.

즉, 똑같은 kkongchi라는 계정으로 로그인을 해도 기존에 썼던 게시물은 내가 쓴 것이 아니게 되는 이상한 현상이 벌어지는 것이다. 결국 내가 그전에 썼던 게시물을 수정하거나 삭제하지 못하게 된다. 물론 불편한 대로 쓸 수는 있겠지만, 깔끔하지가 못했다.

그래서 조사해본 결과, 다음 문서를 Microsoft의 Support Knowledge Base에서 찾을 수 있었다.

After you migrate a user from a different Active Directory domain, the user can no longer access Windows SharePoint Services

위 문서는 사실 내 경우와는 좀 다르다고 하겠다. 위 문서는 Sharepoint Service의 MIgration 시에 할 수 있는 것들을 자세하게 다루고 있다. 하지만 아래 쪽에 보면 STSADM 유틸리티를 사용해서 User를 Migrate할 수 있는 방법을 알려주고 있다. 내가 원하는 것은 바로 이것이었다.

stsadm -o migrateuser -oldlogin DOMAIN\user -newlogin DOMAIN\user [-ignoresidhistory]

위 방법을 써서 바로 현재 사용자들과 기존 사용자들을 Sync시킬 수 있었다. 이제 완전히 같은 환경이 된 것이다. 그러나...

To Be Continued...
Posted by kkongchi
Sharepoint Portal Server2007. 11. 22. 22:45
Sharepoint Service 3.0 사이트에서, 상단 검색 창을 이용해서 검색을 하면 이런 에러가 날 수도 있다.

"Your search cannot be completed because this site is not assigned to an indexer. Contact your administrator for more information."

에러 화면은 다음과 같다.

사용자 삽입 이미지


이 문제의 원인은, Sharepoint 웹 애플리케이션을 새로 만들 때 검색 서버를 할당을 하지 않았기 때문이다. 보통은 검색 서버를 할당을 하겠지만, 하지 않았다면 이렇게 검색 기능 자체를 아예 쓰지 못하게 된다.

해결책은? 당연한 말이겠지만, 웹 애플리케이션에 검색 서버를 할당하면 된다. 그런데 이게 조금 찾기가 힘들다. 왜냐하면, 웹 애플리케이션을 만들 때는 그 만드는 화면에서 검색 서버를 할당하는 옵션이 있기 때문에, 웹 애플리케이션 수정 같은 곳에 있지 않겠나 싶어서 찾아보면 그런 메뉴 자체가 없기 때문이다.

방법은 다음과 같다.

1. Sharepoint Central Administration 사이트를 연다.

2. 상단 탭에서 Application Management를 선택한다.

3. Sharepoint Web Application Management 그룹에 있는 "Content Database"메뉴를 클릭한다.

사용자 삽입 이미지


4. 그러면 Content database 리스트가 뜨는데, 검색 기능을 활성화하고자 하는 사이트가 사용하는 database를 선택해서 클릭한다.

사용자 삽입 이미지


5. 그러면 거기에서 Search Server를 할당할 수 있을 것이다.

사용자 삽입 이미지


이 스텝을 그대로 하면, 검색 기능이 활성화될 것이다. Sharepoint Service의 검색 기능은 매우 막강하므로 (워드, 엑섹 등의 오피스 문서의 내용도 인덱싱을 해주므로, 내용으로 검색도 가능하다.) Sharepoint service를 쓴다면 검색 기능을 활성화해놓고 사용하는 것이 좋을 것이다.
Posted by kkongchi
asp.net2007. 11. 22. 00:00

현재 우리 회사 솔루션의 ASP.NET 웹 애플리케이션에는, 빈번하게 사용되는 개인 정보(혹은 설정값)을 담는 용도로 쿠키를 사용하고 있다. 쿠키는 사실 참 편리하다. 서버의 리소스를 점유하지도 않고, 만료기간만 지정해두면 서버가 다운되건 말건 계속 유지도 되고.. 서버사이드, 클라이언트 사이드 어디서나 쉽게 접속할 수 있기도 하고.

하지만, 솔루션에 대한 보안 감사 끝에.. 쿠키를 제거하기로 결정이 되었다. 사실 보안 측면에서 보자면 쿠키라는 것은 꽤 위험하다. 문제는 이 쿠키가 클라이언트에 저장되는 Plain Text파일인데다가, 모든 Web Server에 대한 Request/Response시에 전송이 된다는 것이다. 즉, 클라이언트에서 이 파일을 열어 볼 수도 있고, 네트워크 패킷을 스니핑해서 내용을 볼 수도 있다. 거기다가 위/변조하기도 당연히 쉽다. 또 일부 국가 - 어딘지는 잘 모른다 - 에서는 법적으로 쿠키를 금지하기도 하고, Internet Explorer등의 브라우저에서도 쿠키를 허용하지 않는 옵션을 장착하고 있기 때문에 어떤 사용자들의 경우 쿠키를 아예 사용할 수 없을 가능성도 있는 것이다.

서두가 장황했는데, 암튼 쿠키를 모두 제거하기로 하고 우리가 선택한 대안은 ASP.NET 세션이었다. 사실 빈번하게 사용되는 사용자 개인의 설정값등을 담아둘 수 있는 가장 이상적인 공간이기도 하고, 쿠키와 매우 유사하게 서버사이드에서 사용할 수도 있기 때문이었다. 하지만 이 ASP.NET 세션에는 한 가지 문제가 있다. 그 문제는 바로, 이 ASP.NET 세션이 기본적으로 쿠키를 사용한다는 것이다.

ASP.NET 세션을 사용하면 생성되는 쿠키는 이렇게 생겼다.

ASP.NET_SessionId=d1ucyg30qyjw1f554szadoqy;

즉, ASP.NET 세션에서 각 사용자를 구분하는 것 자체가 이 쿠키를 사용하는 것이다.

그런데, ASP.NET에는 Cookie-less Session이라고 해서, 쿠키를 사용하지 않고 세션을 사용할 수 있게 해주는 모드 또한 있다. 이것은 별도의 코딩이 필요한 것은 아니고 단지 Web.Config의 SessionState 부분에 Cookieless를 True로 바꿔주기만 하면 된다.

<sessionState
            mode="InProc"
            stateConnectionString="tcpip=127.0.0.1:42424"
            sqlConnectionString="data source=127.0.0.1;Trusted_Connection=yes"
           
cookieless="true"
            timeout="20"
    />

이 Cookie-less Session에 대한 자세한 내용은 Dino Esposito씨의 다음 Article을 보면 알 수 있다.

위 아티클을 보면 알 수 있겠지만, 이 Cookieless Session은 세션을 쓰면서도 Cookie를 완전히 쓰지 않아도 된다는 점에서 나의 고민을 완벽하게 해주는 것이었다. 그러나 나는 몇 가지 문제를 발견했다..-_-;;

첫째로 이 Cookieless Session을 쓸 경우 모든 URL이 조금씩 바뀌게 된다는 것이다. 즉, 요청한 URL이 이렇다면..

http://localhost/CookielessSessionWebSample/Webform1.aspx

실제로 페이지가 열린 다음에는 이렇게 바뀌게 된다.

http://localhost/CookielessSessionWebSample/(mkwgif552tavi2vtxhgq1a45)/Webform1.aspx

위의 URL에 가운데 부분에 이상하게 끼어든 (mkwgif552tavi2vtxhgq1a45)이 바로 쿠키의 SessionID의 역할을 하는 것이다. 즉 쿠키를 쓰는 대신에 URL에 세션ID를 넣어서 사용한다고 생각하면 되겠다.

두번째로 바로 위 사실 때문에 몇가지 제약 사항이 발생한다. Server.Transfer와 Response.Redirect 등을 사용할 때, Root로부터 시작하는 URL 즉 이런 형태 - /RootDir/Somepage.aspx - 를 사용하지 못하며, Full URL - http://ServerName/RootDir/Somepage.aspx - 를 또한 사용하지 못한다. 이 사실은 EggHeadCafe라는 사이트의 한 게시물에서 알게 되었다.

첫번째 문제가 Accept된다면, 사실 대부분의 경우 큰 문제는 없을 것이다. 두번째처럼 만약 코딩을 했다는 것은, 사실 코딩 상에 문제가 있는 거라고 봐야 하니까. 그런데 내 경우는 우리 회사의 솔루션에 저런 것이 없다고 장담하기가 힘들었다는 것이다. 그래서, 우리 솔루션의 경우는 쿠키의 세션ID는 허용하는 방향으로 가기로 했다.

하지만, 쿠키를 완전히 사용할 수 없는 경우가 발생한다면, Cookie-less Session은 매우 좋은 선택이 될 것이다. 그리고 이 Cookie-less Session을 사용한다면 위에서 언급한 코딩상의 주의 사항은 반드시 지켜야 할 것이다.

Posted by kkongchi
MS-SQL2007. 11. 9. 23:28

죽어버린 Sharepoint 팀 사이트를 살려라. 사건개요 보기

사고 직후, DB를 SQL Management Studio를 열었더니 DB는 오프라인 상태로 되어 있었고, DB 이름 옆에 (Suspect)라고 되어 있었다. DB에 손상이 있었구나라는 짐작을 할 수 있었다.

참고로 Database의 각 State는 다음과 같다.

상태 정의

ONLINE

데이터베이스는 접속이 가능한 상태이다. 비록 리커버리의 Undo가 끝나지 않았어도 , 프라이머리 파일 그룹이 온라인 상태이다.

OFFLINE

데이터베이스는 접속 불가능한 상태이다. 사용자가 명시적으로 offline으로 지정했다면, 그것을 다시 되돌리기 전까지는 데이터베이스는 계속 offline상태로 머무르게 된다. 예를 들면 새로운 디스크로 파일을 옮기기 위해서 offline모드로 바꿀 수 있다. 이 파일 이동 작업이 끝나면 다시 online으로 되돌릴 수 있다.

RESTORING

프라이머리 파일 그룹의 하나 이상의 파일이 복구되고 있을 때, 혹은 세컨더리 파일 그룹의 파일이 복구되고 있는 상태이다. 데이터베이스 접속은 불가능하다.

RECOVERING

데이터베이스가 리커버리되고 있는 상태이다. 리커버리 프로세스는 일시적인 것으로, 리커버리가 성공되면 자동적으로 데이터베이스는 온라인 상태로 복구된다. 하지만 리커버리가 실패하면 데이터베이스는 suspect 상태로 바뀌게 된다. 이 때도 역시 데이터베이스 접속은 불가능하다.

RECOVERY PENDING

리커버리 도중에 리소스 관련 문제가 발생한 상태이다. 데이터베이스가 손상된 것은 아니지만, 파일이 없어졌을 수도 있고 시스템 상의 리소스 제약때문에 문제가 발생했을 수도 있다. 데이터베이스 접속은 불가능하다. 이 문제를 풀기 위해서는 사용자의 행동이 필요하며, 그래야만이 리커버리 프로세스가 완료될 수 있다.

SUSPECT

프라이머리 파일 그룹에 문제가 있거나 손상된 것이다. SQL 서버를 다시 시작시켜도 데이터베이스는 복구되지 않는다. 데이터베이스 접속은 불가능하다. 문제를 해결하기 위해서는 사용자의 행동이 필요하다.

EMERGENCY

이 상태는 사용자가 설정했을 때만 가능하다. 데이터베이스가 single-user 모드일 때에만 데이터베이스는 수리(Repair)와 복원이 가능하다. 이때 데이터베이스는 읽기 전용이며 로깅이 꺼지며 sysadmin 그룹의 사용자만이 접속이 가능하다. 이 Emergency 상태는 장애 복구의 용도로 사용된다. 예를 들면 Suspect 상태의 데이터베이스는 Emergency상태로 설정할 수 있다. 이 때 system administrator는 데이터베이스에 읽기 전용으로 접속할 수 있다. sysadmin그룹의 사용자만이 데이터베이스를 Emergency상태로 설정할 수 있다.

* 죄송하게도 번역이 매끄럽지 못하다. -_-;; 그래도 제 딴에는 최선을 다한 것이니 양해 부탁드린다. 오역이 있다면 덧글로 남겨주시길.. 원본은 SQL 2005 help이다.



가장 내가 우선적으로 해야 할 일은 DB를 살리는 것이었다. suspect 상태의 DB를 살리기 위해서 구글신에게 물어보았더니, 아래와 같은 답을 주셨다.

How to Restore SQL Server 2005 Suspect Database - The Code Project

위 페이지에서 제시하는 해답은 다음과 같다. 아래의 스텝을 순서대로 하면 되겠다.

1. EXEC sp_resetstatus 'yourDBname';

일단, DB에서 Suspect 마크를 없앤다. sp_resetstatus는 바로 그 일을 해주는 내장 스토어드 프로시저이다.

2. ALTER DATABASE yourDBname SET EMERGENCY

데이터베이스 상태를 Emergency로 바꾼다.

3. DBCC checkdb('yourDBname')

Emergency모드이므로, 현재 데이터베이스는 읽기 전용이다. 이 상태에서 먼저 CheckDB를 수행해서 DB문제점을 파악한다.

4. ALTER DATABASE yourDBname SET SINGLE_USER WITH ROLLBACK IMMEDIATE

Repair를 위해서, DB상태를 Sigle User 모드로 바꾼다.

5. DBCC CheckDB ('yourDBname', REPAIR_ALLOW_DATA_LOSS)

CheckDB를 통해서 Repair를 수행하는데, REPAIR_ALLOW_DATA_LOSS옵션을 사용한다. 위에 링크한 원본 글에도 나와 있지만, 이 옵션외에는 쓸 수가 없다. (위 글의 저자는 자신의 경우 어떤 데이터 LOSS도 없었다고 하는데, 실제로 나는 데이터를 다소 잃었다. -_-;; 이건 팔자려니 생각하자.)

6. ALTER DATABASE yourDBname SET MULTI_USER

Repair가 끝났다면 Database를 다시 Multi User모드로 복원시키면 된다.

위 스텝을 정리하자면 다음과 같다.

EXEC sp_resetstatus 'yourDBname';
ALTER DATABASE yourDBname SET EMERGENCY
DBCC checkdb('yourDBname')
ALTER DATABASE yourDBname SET SINGLE_USER WITH ROLLBACK IMMEDIATE
DBCC CheckDB ('yourDBname', REPAIR_ALLOW_DATA_LOSS)
ALTER DATABASE yourDBname SET MULTI_USER




이 스텝을 통해서, Suspect 상태의 DB를 거의 복구시킬 수 있었다. 아마 대부분의 경우 위 스텝으로 거의 100% 복구가 가능할 것이라 생각되나.. 내 경우는 조금 달랐다. 문제는 디스크에 오류가 있기 때문에, DB는 복구가 되었지만 Sharepoint 는 문제가 계속 있었던 것이다. 데이터의 읽기는 아무런 문제없이 정상적인데, 문서를 올리거나 게시물을 작성하면 2번에 1번 꼴로 에러가 발생했다. 그래서 어쩔 수 없이 DB를 포함해서 모두를 다른 서버로 옮기기로 했다. 이 이야기는 다음에..

To Be Continued...

Posted by kkongchi
Sharepoint Portal Server2007. 11. 9. 23:21

사내에 개발팀의 Communcation 도구 및 자료 저장소/Wiki라이브러리로 Windows Sharepoint Service 3.0을 사용하고 있다. 관리 책임이 나에게 있던 사이트였지만, 평소에 그다지 신경을 그다지 쓰지는 않았다. 백업이라도 해 뒀어야 하는데..-_-;;

암튼 결국 사고가 터졌다. 약 한달전 사이트가 갑자기 느려지더니 결국 1시간만에 조용히 죽어버렸다... 원인은 하드 디스크의 Bad Block.. 그것도 Sharepoint의 데이터를 저장하는 SQL 데이터 파일에서 발생...

암튼 이 사고로 인해서 죽어버린 Sharepoint Service를 다시 살리는데 아주 고생을 했다. 아래는 나의 그 고생을 기록한 경험담이다..-_-;

1. Suspect 상태의 DB를 살려라
2. 계정을 싱크해라
3. 새로운 서버로의 이전

Posted by kkongchi
C# & VB.NET2007. 10. 17. 21:24

C#에서 문자열 내부에 "를 쓸때는 Escape 문자인 \를 써서 표현을 해야 한다. 아래와 같이

 

string s = "\"Lazy\" \"Developer\"";

 

이 경우 실제 문자열은  "Lazy" "Developer" 이렇게 인식을 하게 되는 것이다.

 

VB.NET에서는 "를 써서 똑같은 효과를 볼 수 있다.

 

Dim str As String = """Lazy"" ""Developer"""
Posted by kkongchi
windows2007. 10. 17. 10:44

터미널 서비스를 사용해서 서버에 접속했을 때, Ctrl+Alt+Del 키를 누르면 터미널로 접속한 서버가 아니라 자신의 PC에서 Windows Security Menu가 뜬다. 그래서 오늘 나는 터미널 서비스로 서버에 접속해서 Administrator의 패스워드를 바꾸고 싶었는데, 어떻게 해야 할지 몰라서 조금 헤멨다.


Windows Terminal Service 의 Help를 통해서 알게 된 결론은..

터미널 서비스로 접속한 상태에서 Ctrl+Alt+End를 누르는 것이다. 그러면 터미널 서비스로 접속한 서버 안에서 다음과 같이 Security Menu가 뜰 것이다.



Windows Terminal Service Help에 나와있는 전체 단축키들 목록은 다음과 같다.

ALT+PAGE UP

Switches between programs from left to right.

ALT+PAGE DOWN

Switches between programs from right to left.

ALT+INSERT

Cycles through programs in the order that they were started in.

ALT+HOME

Displays the Start menu.

CTRL+ALT+BREAK

Switches between a window and a full screen.

CTRL+ALT+END

Displays the Windows Security dialog box.

ALT+DELETE

Displays the Windows menu.

CTRL+ALT+Minus (-) symbol on the numeric keypad

Places a copy of the active window, within the client, on the remote computer's clipboard (provides the same functionality as pressing ALT+PRINT SCREEN on a local computer).

CTRL+ALT+Plus (+) symbol on the numeric keypad

Places a copy of the entire client window area on the remote computer's clipboard (provides the same functionality as pressing PRINT SCREEN on a local computer).

CTRL+ALT+RIGHT ARROW

Enables you to “tab” out of the Remote Desktop controls to a control in the host program (for example, a button or a text box). Useful when the Remote Desktop controls are embedded in another (host) program.

CTRL+ALT+LEFT ARROW

Enables you to “tab” out of the Remote Desktop controls to a control in the host program (for example, a button or a text box). Useful when the Remote Desktop controls are embedded in another (host) program.

Posted by kkongchi