Consideraciones sobre aplicaciones

1
Consideraciones sobre aplicaciones
John.Thorburn_at_eu.citrix.comSystem
EngineeringCitrix Spain
2
Agenda

• Intro
• Buenas prácticas para el desarrollo
• Notas genéricas para instalar Apps
• Issues
• Otras Cosas

3
Intro

• En el entorno de Terminal Services las cosas no
  son exactamente igual para las aplicaciones,
  porque es un entorno multiusuario
• Componentes fundamentales de win2000 han sido
  modificados para Terminal Services, por ejemplo
• Object Manager, modificado para permitir la
  virtualización de objetos como mutant, timer,
  semaphore, process, thread etc. De esta forma,
  aplicaciones y programas del sistema de distintas
  sesiones no chocan. Cada objeto creado dentro de
  una sesión está asociado a un identificador único
  que se llama SessionID.
• El Virtual Memory hace mapeo de direcciones
  virtuales de procesos a páginas físicas en la
  memoria del ordenador. En NT el espacio está
  dividido en 2GB para el user (process-specific
  addresses) y 2GB para el kernel (system-address
  addresses). Para el espacio de user el Virtual
  Memory Manager da una vista individual de la
  memoria física asegurando que cada thread de un
  proceso puede acceder a su memoria, pero no a la
  memoria de otros.

4
Intro 2

• Al contrario, el espacio de direcciones para el
  kernel es común para todos los procesos dentro
  del sistema, de esta forma se permite un acceso
  constante para acceder a los servicos del kernel.
  El hecho de que todos los procesos compartan el
  espacio de direcciones para el kernel resulta
  en limitaciones de recursos con múltiples
  sesiones. En Terminal services estas limitaciones
  han sido arregladas con la creación del
  SessionSpace que puede ser mapped por cada
  sesión. Cada proceso está asociado con un
  SessionSpace, vía el SessionID.
• Cuando un nuevo usuario se conecta a un terminal
  server, un nuevo SessionID es generado, y todos
  los procesos asociados usan el SessionID creado y
  el SessionSpace asociado. Otros grupos de
  procesos con un SessionID distinto apuntan a un
  grupo de objetos mapeado en memoria y páginas
  físicas en la misma dirección virtual

5
Intro 3

• El Servicio termsvcs de Windows 2000 tiene la
  responsabilidad de controlar los procesos en un
  entorno de Terminal Server. Su primera obligación
  es session management, inicio y terminación de
  sesiones de los usuarios y notificación de
  eventos. Termsvcs es independiente de protocolo,
  así que puede utilizar tanto RDP o ICA
• Es decir algo distinto de un win2000 Workstation

6
Buenas prácticas para el desarrollo de apps 1

• Ver en MS,
• http//www.microsoft.com/windows2000/technologies/
  terminal/default.asp
• TSAppDev.doc,
• w2kspec-desktop.doc,
• W2kTSApCmpt.doc
• Ver en Citrix
• CTX846521
• Comprehensive Application Tuning Document
• CTX599154
• How to Troubleshoot Application Integration
  Issues

7
Buenas practicas para el desarrollo de apps 2

• Donde más se mete la pata es
• Instalación.
• Separación de datos del usuario y datos globales.
  
• Programación para multiusuario

8
Buenas prácticas para el desarrollo de apps 3
Instalación 1/2

• Application installation is different when
  Terminal Services is enabled in Windows 2000
  Server. The registry and .ini file mapping
  support that is built into Terminal Services
  allows applications that were not originally
  designed to run in a multiuser environment to run
  correctly under Terminal Services. This means
  that users should be able to execute these
  applications simultaneously and save whatever
  preferences the application allows for each of
  them. Of course, each user must have a unique
  home directory. If no home directory is specified
  for a user by the administrator, the users home
  directory defaults to his or her user profile
  directory, \Wtsrv\Profiles\Username.
• To enable each user to retain individual
  application settings, he or she must have a
  unique copy of the appropriate .ini files or
  registry entries. To accomplish this, Terminal
  Services replicates the .ini files and registry
  entries from a common system location to each
  user as necessary. For .ini files, this means
  that the .ini files in the system directory
  (systemroot) will be copied to each users
  Windows directory. For registry entries, the
  registry entries will be copied from
  HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\C
  urrentVersion\Terminal Server\Install\Software to
  HKEY_CURRENT_USER\Software.
• In order for Terminal Services to replicate the
  necessary registry entries or .ini files for each
  user, the user must install the application in
  Install mode. This is accomplished by using
  Add/Remove Programs in Control Panel. Install
  mode may also be enabled from the command line
  after executing the change user /install command,
  though using Add/Remove Programs is preferable.
  If the administrator uses this function,
  application installation should properly allow
  for user-specific application settings. The
  built-in Windows Installer service included in
  Windows 2000 Server will be the best way for
  application developers to ensure correct
  installation. For more information on the Windows
  Installer service, see the current guidelines for
  the Windows 2000 Logo program
• Disallow Installing Multiple Versions of
  Applications with Shared DLLs
• Because many application versions share DLLs,
  only one version of an application can be run at
  a time. If multiple versions are installed on the
  system, it is very possible that different users
  will attempt to run various versions of the same
  application simultaneously. For example, both
  Microsoft Internet Explorer 3.x and Microsoft
  Internet Explorer 4.x share various DLLs that
  will fail to work properly when both versions are
  installed on the same server.
• Application Installation or Compatibility Scripts
• If an older application does not install
  properly, an Application Compatibility Script may
  be needed to correct installation problems with
  the registry or other issues. Scripts for many
  popular applications such as Microsoft Office are
  included with Windows 2000 Server Terminal
  Services. Additional information on these scripts
  can be found on the Microsoft Web site in the
  white paper "Using and Developing Applications
  Compatibility Scripts."

9
Buenas practicas para el desarrollo de apps 4
Instalación 1/2

• Application installation is different when
  Terminal Services is enabled in Windows 2000
  Server. The registry and .ini file mapping
  support that is built into Terminal Services
  allows applications that were not originally
  designed to run in a multiuser environment to run
  correctly under Terminal Services. This means
  that users should be able to execute these
  applications simultaneously and save whatever
  preferences the application allows for each of
  them. Of course, each user must have a unique
  home directory. If no home directory is specified
  for a user by the administrator, the users home
  directory defaults to his or her user profile
  directory, \Wtsrv\Profiles\Username.
• To enable each user to retain individual
  application settings, he or she must have a
  unique copy of the appropriate .ini files or
  registry entries. To accomplish this, Terminal
  Services replicates the .ini files and registry
  entries from a common system location to each
  user as necessary. For .ini files, this means
  that the .ini files in the system directory
  (systemroot) will be copied to each users
  Windows directory. For registry entries, the
  registry entries will be copied from
  HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\C
  urrentVersion\Terminal Server\Install\Software to
  HKEY_CURRENT_USER\Software.
• In order for Terminal Services to replicate the
  necessary registry entries or .ini files for each
  user, the user must install the application in
  Install mode. This is accomplished by using
  Add/Remove Programs in Control Panel. Install
  mode may also be enabled from the command line
  after executing the change user /install command,
  though using Add/Remove Programs is preferable.
  If the administrator uses this function,
  application installation should properly allow
  for user-specific application settings. The
  built-in Windows Installer service included in
  Windows 2000 Server will be the best way for
  application developers to ensure correct
  installation. For more information on the Windows
  Installer service, see the current guidelines for
  the Windows 2000 Logo program
• Disallow Installing Multiple Versions of
  Applications with Shared DLLs
• Because many application versions share DLLs,
  only one version of an application can be run at
  a time. If multiple versions are installed on the
  system, it is very possible that different users
  will attempt to run various versions of the same
  application simultaneously. For example, both
  Microsoft Internet Explorer 3.x and Microsoft
  Internet Explorer 4.x share various DLLs that
  will fail to work properly when both versions are
  installed on the same server.
• Application Installation or Compatibility Scripts
• If an older application does not install
  properly, an Application Compatibility Script may
  be needed to correct installation problems with
  the registry or other issues. Scripts for many
  popular applications such as Microsoft Office are
  included with Windows 2000 Server Terminal
  Services. Additional information on these scripts
  can be found on the Microsoft Web site in the
  white paper "Using and Developing Applications
  Compatibility Scripts."

10
Buenas prácticas para el desarrollo de apps 5
Separación de datos del usuario y datos globales

• Separation of Local and Global Data
• Use the HKEY_LOCAL_MACHINE Properly
• In the Terminal Services environment, each user
  receives a HKEY_CURRENT_USER registry hive at
  logon time that stores user-specific information
  however, all users share the HKEY_LOCAL_MACHINE
  hive. This means that any information placed in
  the HKEY_LOCAL_MACHINE hive affects all users,
  while information placed in the HKEY_CURRENT_USER
  hive affects only one user session.
• Some applications make the assumption that one
  machine equates to one user, and they store user
  information in the HKEY_LOCAL_MACHINE hive. This
  practice can create serious problems in a
  multiuser environment. With this in mind,
  applications should properly separate global
  registry information from local (user) registry
  information, and store information in the correct
  hive.
• Do Not Store Local Data Constructs in Global
  Locations
• In addition to separating global and local
  information in the registry, global and local
  file-based data constructs should also be
  maintained separately. For example, user
  preference files should not be stored in the
  system directory (for example, Winnt) or program
  directory (for example, Program Files)
  structures. Instead, preference files or other
  user-specific local data constructs should be
  stored in the user's home directory or a
  user-specified directory.
• This consideration also applies to temporary
  files used to store interim information (such as
  cached data) or to pass data on to another
  application. User-specific temporary files must
  also be stored on a per-user basis.

11
Buenas prácticas para el desarrollo de apps 6
Programación para multiusuario 1/3

• Programming for the Multiuser
• Disallowing Multiple Instances of Some
  Applications
• There are some types of applications that should
  only run with one instance on the server.
  Typically, these are applications that monitor or
  manage system resources, such as a disk
  administration program. These applications should
  check if they are already running and not
  initiate a second application process. In
  particular, if an application of this type polls
  a system resource continually, multiple instances
  of the application are not needed, and instead
  could seriously degrade system performance.
• Resolve Memory Leaks
• The danger of memory leaks is intensified in the
  Terminal Services environment. A memory leak in a
  program running in the traditional Windows client
  environment will eventually cause trouble, but
  may in fact be masked by the fact that the
  desktop device is turned on and off frequently
  and memory is thus cleared. In the Terminal
  Services environment, that same application can
  be run multiple times by multiple users, thus
  rapidly magnifying the effect of a memory leak.
• Do Not Assume Computer Name or IP AddressEquates
  to Single User
• In the traditional distributed Windows-based
  client/server architecture, one user is logged on
  to one computer at a time therefore, the
  computer name or Internet Protocol (IP) address
  assigned to either a desktop or server computer
  equate to one user. In the Terminal Services
  environment, the application can only see the IP
  or NetBIOS address of the Terminal Server.
• Applications that use the computer name or IP
  address for licensing or as a means of
  identifying an iteration of the application on
  the network will not work properly in the
  Terminal Services environment because the
  servers computer name or IP address can really
  equate to many different desktops or users.
• Do Not Assume the Windows Shell
• Some applications assume that the Windows shell
  (including the browser) will be running and use
  these as resources in the application. If the
  administrator chooses, Terminal Services allows
  applications to run entirely without the shell or
  desktop. This feature is provided so
  administrators can lock down a client session and
  deny the user access to anything except a single
  application. This feature can be used in a
  task-based worker environment, where limiting
  end-user access to the desktop and file system
  reduces potential security or configuration
  problems, and reduces help-desk costs.
• Do Not Assume Persistence of Files in Temp
• Dont assume persistence of any files in the Temp
  folder beyond the current user session on any
  machine, because administrators can set a policy
  to delete everything in the Temp folder each time
  the user logs on. For example, if a recovery file
  that is regularly updated during an editing
  session is be stored in the Temp folder it may
  not be present to restore changes if an
  application crashes. Also, these types of files
  are clearly per-user, so they should be saved in
  the Application Data folder in the User Profile,
  where the appropriate file security is also in
  place so others cannot view the file. An
  administrator in an enterprise environment may
  also configure Terminal Services to save per user
  Application Data in a directory on a completely
  separate file server for recoverability reasons,
  particularly in a multi-server farm
  configuration.

12
Buenas prácticas para el desarrollo de apps 7
Programación para multiusuario 2/3

• Programming for the Multiuser
• Disallowing Multiple Instances of Some
  Applications
• There are some types of applications that should
  only run with one instance on the server.
  Typically, these are applications that monitor or
  manage system resources, such as a disk
  administration program. These applications should
  check if they are already running and not
  initiate a second application process. In
  particular, if an application of this type polls
  a system resource continually, multiple instances
  of the application are not needed, and instead
  could seriously degrade system performance.
• Resolve Memory Leaks
• The danger of memory leaks is intensified in the
  Terminal Services environment. A memory leak in a
  program running in the traditional Windows client
  environment will eventually cause trouble, but
  may in fact be masked by the fact that the
  desktop device is turned on and off frequently
  and memory is thus cleared. In the Terminal
  Services environment, that same application can
  be run multiple times by multiple users, thus
  rapidly magnifying the effect of a memory leak.
• Do Not Assume Computer Name or IP AddressEquates
  to Single User
• In the traditional distributed Windows-based
  client/server architecture, one user is logged on
  to one computer at a time therefore, the
  computer name or Internet Protocol (IP) address
  assigned to either a desktop or server computer
  equate to one user. In the Terminal Services
  environment, the application can only see the IP
  or NetBIOS address of the Terminal Server.
• Applications that use the computer name or IP
  address for licensing or as a means of
  identifying an iteration of the application on
  the network will not work properly in the
  Terminal Services environment because the
  servers computer name or IP address can really
  equate to many different desktops or users.
• Do Not Assume the Windows Shell
• Some applications assume that the Windows shell
  (including the browser) will be running and use
  these as resources in the application. If the
  administrator chooses, Terminal Services allows
  applications to run entirely without the shell or
  desktop. This feature is provided so
  administrators can lock down a client session and
  deny the user access to anything except a single
  application. This feature can be used in a
  task-based worker environment, where limiting
  end-user access to the desktop and file system
  reduces potential security or configuration
  problems, and reduces help-desk costs.
• Do Not Assume Persistence of Files in Temp
• Dont assume persistence of any files in the Temp
  folder beyond the current user session on any
  machine, because administrators can set a policy
  to delete everything in the Temp folder each time
  the user logs on. For example, if a recovery file
  that is regularly updated during an editing
  session is be stored in the Temp folder it may
  not be present to restore changes if an
  application crashes. Also, these types of files
  are clearly per-user, so they should be saved in
  the Application Data folder in the User Profile,
  where the appropriate file security is also in
  place so others cannot view the file. An
  administrator in an enterprise environment may
  also configure Terminal Services to save per user
  Application Data in a directory on a completely
  separate file server for recoverability reasons,
  particularly in a multi-server farm
  configuration.

13
Buenas prácticas para el desarrollo de apps 8
Programación para multiusuario 3/3

• Programming for the Multiuser
• Disallowing Multiple Instances of Some
  Applications
• There are some types of applications that should
  only run with one instance on the server.
  Typically, these are applications that monitor or
  manage system resources, such as a disk
  administration program. These applications should
  check if they are already running and not
  initiate a second application process. In
  particular, if an application of this type polls
  a system resource continually, multiple instances
  of the application are not needed, and instead
  could seriously degrade system performance.
• Resolve Memory Leaks
• The danger of memory leaks is intensified in the
  Terminal Services environment. A memory leak in a
  program running in the traditional Windows client
  environment will eventually cause trouble, but
  may in fact be masked by the fact that the
  desktop device is turned on and off frequently
  and memory is thus cleared. In the Terminal
  Services environment, that same application can
  be run multiple times by multiple users, thus
  rapidly magnifying the effect of a memory leak.
• Do Not Assume Computer Name or IP AddressEquates
  to Single User
• In the traditional distributed Windows-based
  client/server architecture, one user is logged on
  to one computer at a time therefore, the
  computer name or Internet Protocol (IP) address
  assigned to either a desktop or server computer
  equate to one user. In the Terminal Services
  environment, the application can only see the IP
  or NetBIOS address of the Terminal Server.
• Applications that use the computer name or IP
  address for licensing or as a means of
  identifying an iteration of the application on
  the network will not work properly in the
  Terminal Services environment because the
  servers computer name or IP address can really
  equate to many different desktops or users.
• Do Not Assume the Windows Shell
• Some applications assume that the Windows shell
  (including the browser) will be running and use
  these as resources in the application. If the
  administrator chooses, Terminal Services allows
  applications to run entirely without the shell or
  desktop. This feature is provided so
  administrators can lock down a client session and
  deny the user access to anything except a single
  application. This feature can be used in a
  task-based worker environment, where limiting
  end-user access to the desktop and file system
  reduces potential security or configuration
  problems, and reduces help-desk costs.
• Do Not Assume Persistence of Files in Temp
• Dont assume persistence of any files in the Temp
  folder beyond the current user session on any
  machine, because administrators can set a policy
  to delete everything in the Temp folder each time
  the user logs on. For example, if a recovery file
  that is regularly updated during an editing
  session is be stored in the Temp folder it may
  not be present to restore changes if an
  application crashes. Also, these types of files
  are clearly per-user, so they should be saved in
  the Application Data folder in the User Profile,
  where the appropriate file security is also in
  place so others cannot view the file. An
  administrator in an enterprise environment may
  also configure Terminal Services to save per user
  Application Data in a directory on a completely
  separate file server for recoverability reasons,
  particularly in a multi-server farm
  configuration.

14
Buenas prácticas para el desarrollo de apps 8
Programación para multiusuario appendix A,B,C,D!

• Programming for the Multiuser
• Disallowing Multiple Instances of Some
  Applications
• There are some types of applications that should
  only run with one instance on the server.
  Typically, these are applications that monitor or
  manage system resources, such as a disk
  administration program. These applications should
  check if they are already running and not
  initiate a second application process. In
  particular, if an application of this type polls
  a system resource continually, multiple instances
  of the application are not needed, and instead
  could seriously degrade system performance.
• Resolve Memory Leaks
• The danger of memory leaks is intensified in the
  Terminal Services environment. A memory leak in a
  program running in the traditional Windows client
  environment will eventually cause trouble, but
  may in fact be masked by the fact that the
  desktop device is turned on and off frequently
  and memory is thus cleared. In the Terminal
  Services environment, that same application can
  be run multiple times by multiple users, thus
  rapidly magnifying the effect of a memory leak.
• Do Not Assume Computer Name or IP AddressEquates
  to Single User
• In the traditional distributed Windows-based
  client/server architecture, one user is logged on
  to one computer at a time therefore, the
  computer name or Internet Protocol (IP) address
  assigned to either a desktop or server computer
  equate to one user. In the Terminal Services
  environment, the application can only see the IP
  or NetBIOS address of the Terminal Server.
• Applications that use the computer name or IP
  address for licensing or as a means of
  identifying an iteration of the application on
  the network will not work properly in the
  Terminal Services environment because the
  servers computer name or IP address can really
  equate to many different desktops or users.
• Do Not Assume the Windows Shell
• Some applications assume that the Windows shell
  (including the browser) will be running and use
  these as resources in the application. If the
  administrator chooses, Terminal Services allows
  applications to run entirely without the shell or
  desktop. This feature is provided so
  administrators can lock down a client session and
  deny the user access to anything except a single
  application. This feature can be used in a
  task-based worker environment, where limiting
  end-user access to the desktop and file system
  reduces potential security or configuration
  problems, and reduces help-desk costs.
• Do Not Assume Persistence of Files in Temp
• Dont assume persistence of any files in the Temp
  folder beyond the current user session on any
  machine, because administrators can set a policy
  to delete everything in the Temp folder each time
  the user logs on. For example, if a recovery file
  that is regularly updated during an editing
  session is be stored in the Temp folder it may
  not be present to restore changes if an
  application crashes. Also, these types of files
  are clearly per-user, so they should be saved in
  the Application Data folder in the User Profile,
  where the appropriate file security is also in
  place so others cannot view the file. An
  administrator in an enterprise environment may
  also configure Terminal Services to save per user
  Application Data in a directory on a completely
  separate file server for recoverability reasons,
  particularly in a multi-server farm
  configuration.

15
Buenas prácticas para el desarrollo de apps 8
Programación para multiusuario appendix A,B,C,D!

• Programming for the Multiuser
• Disallowing Multiple Instances of Some
  Applications
• There are some types of applications that should
  only run with one instance on the server.
  Typically, these are applications that monitor or
  manage system resources, such as a disk
  administration program. These applications should
  check if they are already running and not
  initiate a second application process. In
  particular, if an application of this type polls
  a system resource continually, multiple instances
  of the application are not needed, and instead
  could seriously degrade system performance.
• Resolve Memory Leaks
• The danger of memory leaks is intensified in the
  Terminal Services environment. A memory leak in a
  program running in the traditional Windows client
  environment will eventually cause trouble, but
  may in fact be masked by the fact that the
  desktop device is turned on and off frequently
  and memory is thus cleared. In the Terminal
  Services environment, that same application can
  be run multiple times by multiple users, thus
  rapidly magnifying the effect of a memory leak.
• Do Not Assume Computer Name or IP AddressEquates
  to Single User
• In the traditional distributed Windows-based
  client/server architecture, one user is logged on
  to one computer at a time therefore, the
  computer name or Internet Protocol (IP) address
  assigned to either a desktop or server computer
  equate to one user. In the Terminal Services
  environment, the application can only see the IP
  or NetBIOS address of the Terminal Server.
• Applications that use the computer name or IP
  address for licensing or as a means of
  identifying an iteration of the application on
  the network will not work properly in the
  Terminal Services environment because the
  servers computer name or IP address can really
  equate to many different desktops or users.
• Do Not Assume the Windows Shell
• Some applications assume that the Windows shell
  (including the browser) will be running and use
  these as resources in the application. If the
  administrator chooses, Terminal Services allows
  applications to run entirely without the shell or
  desktop. This feature is provided so
  administrators can lock down a client session and
  deny the user access to anything except a single
  application. This feature can be used in a
  task-based worker environment, where limiting
  end-user access to the desktop and file system
  reduces potential security or configuration
  problems, and reduces help-desk costs.
• Do Not Assume Persistence of Files in Temp
• Dont assume persistence of any files in the Temp
  folder beyond the current user session on any
  machine, because administrators can set a policy
  to delete everything in the Temp folder each time
  the user logs on. For example, if a recovery file
  that is regularly updated during an editing
  session is be stored in the Temp folder it may
  not be present to restore changes if an
  application crashes. Also, these types of files
  are clearly per-user, so they should be saved in
  the Application Data folder in the User Profile,
  where the appropriate file security is also in
  place so others cannot view the file. An
  administrator in an enterprise environment may
  also configure Terminal Services to save per user
  Application Data in a directory on a completely
  separate file server for recoverability reasons,
  particularly in a multi-server farm
  configuration.

16
DOS y Win16

• En principio no las quieres
• Aplicaciones DOS y Win16 consumen más memoria que
  aplicaciones win32, WOW, VDM
• Aplicaciones DOS pueden hacer polling de teclado,
  raton, etc.
• Fichero sde config comn
• Printing
• Check Out
• http//www.tamedos.com/ for Tame

17

• Q279792
• HOW TO Enable Application Compatibility-Mode
  Technology in Windows 2000 SP2 and SP3

18
Application Integration (AI)

• Gestión de cambios
• Doc/Desatendida/Imagenes/Probar
• Soporte del entorno multiusuario
• Lo de antes
• Seguridad, ficheros y reg
• No vale ser administrador
• Scripts de compatibilidad (ACS)
• systemrootApplication compatability scripts
• Varias fuentes, pero Todd W Mathers es bueno
• Program Compatability Flags
• Issues

19
Application Integration (AI)

• ACS 1
• Para aplicaciones con problemas
• systemrootApplication compatability scripts
• Afecta Config de sistema
• ej rootdrive definicion
• User_Start_Menu locacion
• Correr scripts justo después de instalar app
• usar change user /install
• Correr scripts durante el logon de usuario

20
Application Integration (AI)

• MS incluye
• Usrlogon.cmd estándar system32
• Usrlogn1.cmd system32
• Usrlogn2.cmd system32
• Setpaths.cmd ACS
• RootDrv.cmd ACS
• RootDrv2.cmd ACS
• ChkRoot.cmd ACS
• End.cmd ACS
• Y unos 20-tantos ACSs para ciertas apps
• También ver http//www.xs4all.nl/soundtcr/

21
Application Integration (AI)

• 3 apps de apoyo
• ACINIUPD.exe update INIs
• ACREGL.exe Reg Search output
• ACSR.exe Search y replace file contents
• Y scripting tools como
• kixtart y WSH

22
Application Integration (AI)

• Program Compatability Flags
• Para Application
• INIs
• Registry entries
• Ej. Application
• Para reducir uso de CPU (BadApp)
• HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\
  Windows NT\CurrentVersion\Terminal Server\
  Compatibility\Applications\app_name
• También Appcompat.exe en CD win2000 y
• Ver Q279792.doc

23
Application Integration (AI)

• Proceso de instalación
• Hacer customización de app antes, funciones, MST,
  etc.
• Instalar Change user /install
• Reboot o Change user /execute

24
Application Integration (AI)

• Issues
• Algunas apps intentan escribir en el reg durante
  su primer arranque.test y change user /install
• Algunas apps necesitan acceder al reg o un
  fichero, y no tienen accesousar RegMon y FileMon
• Aplicaciones de 16bit a veces escriben en Win.ini
  y System.ini.refresh con sysedit
• Sólo corre una instancia1/ limitación de
  seguridad en el reg o fichero 2/ .exe o DLL en
  uso por la primera instancia ..probar registrando
  el .exe o dll como system Global
• Sólo corre para el admin pero no para el usuario
  normal .. Reg y file mon

25
Application Integration (AI)

• La aplicación funciona pero luego da error o
  crash.1/posible problema con reg o aceso a
  ficheros..2/ Datos de usuario en app.ini
  filerelocate a systemroot
• Apps esperan un path fijado en código, probar
  Subst en script de logon por usuario
• REM make sure C is not mapped
• Net use /d c
• Subst c /d
• REM now point it at the application drive
• Subst c y\
• DrWatsonpor defecto desabilitarlo con drwtsn32

26
Otra cosas

• RickD apptuning section on tweak citrix
  http//www.tweakcitrix.com/Sections/AppTun.htm
• http//www.microsoft.com/ntserver/ProductInfo/term
  inal/default.asp
• Terminal Server TSE 4.0 web site links etc
• Main web page for windows 2000 terminal services
• http//www.microsoft.com/windows2000/technologies/
  terminal/default.asp

27
Otra cosas

• MSI y MST info link (también ver KB de Citrix)
• http//www.microsoft.com/windows2000/en/server/hel
  p/appmgr_packagemodsTop.htm
• http//www.microsoft.com/technet/treeview/default.
  asp?url/technet/prodtechnol/win2kts/maintain/opti
  mize/secw2kts.asp
• Securing Windows 2000 Terminal Services, White
  Paperby David Mackey
• The Application Security tool is available with
  the Windows 2000 Server Resource Kit. To learn
  more about the Appsec tool, refer to the
  following white paper at http//www.microsoft.com/
  windows2000/techinfo/reskit/tools/hotfixes/appsec-
  o.asp.

28
Otra cosas

• TScale
• http//www.rtosoft.com/

29
Otra cosas

• Auto-End Tasks
• If an application does not properly exit when
  closed or upon server shutdown, the operating
  system can terminate the application using
  Auto-End Tasks. Auto-End Tasks terminates any
  task that does not respond to a shutdown notice
  within the default timeout period.
  HKEY_USERS\.DEFAULT\Control Panel\Desktop Value
  AutoEndTasks (REG_SZ) 1
• Value WaitToKillAppTimeout (REG_SZ) x, where x
  is the interval in milliseconds (default is
  20000)
• VER Q123058 and Q191805.

30
Testing Apps - Compatibilidad

• Desde
• http//www.microsoft.com/windowsserver2003/partner
  s/isvs/cfwfaq.mspx
• .Where can I find tools for testing applications
  running on Windows Server 2003?
• A.There are three main tools AppVerifier,
  Compatibility Administrator, and Compatibility
  Analyzer.

31
Testing Apps - Stress Test

• Citrix, Desde el CDN check out the CSTK
• Mercury Interactive
• www.mercuryinteractive.com/ -
• http//www.scapatech.com/home.html

32
Preguntas?