Lo que ocurre normalmente es lo siguiente:
Si el disco extraible tiene formato ntfs, windows recuerda siempre la configuracion de las carpetas compartidas.
Si el disco extraible tiene formato fat32, windows se olvida de los recursos compartidos luego de un reinicio.
O sea que, en los casos en que el disco es extraido periodicamente, es conveniente que el formato sea ntfs.
Sin embargo ocurre un segundo problema y es el cambio de letra. Si windows cambiara la letra del dispositivo, entonces el recurso deja de estar compartido.
Una solucion a ambos problemas y que sirve para cualquiera de los dos sistemas (ntfs, fat32) es el siguiente script o archivo batch (extension bat):
El que sigue es un ejemplo para el caso de un pendrive cuyo nombre de volumen (1) es Sistemas y la carpeta a compartir se llama Ventas y está en el raiz del disco extraible, por ejemplo: C:\Ventas
echo ESTE SCRIPT REQUIERE QUE EXISTA UN DIRECTORIO C:\Compartir !!!!!!
cd c:\compartir
echo list volume | diskpart | find /i "Sistemas" > prueba.txt
for /f "tokens=3" %%i in (prueba.txt) do net share Ventas=%%i:\Ventas /unlimited
Podria utilizarse la carpeta de sistema Temp, en lugar c:\Compartir y de ese modo se evita tener que crear dicha carpeta. Cuestion de gustos.
La necesidad del comando cd c:\compartir ocurre porque no logré que el comando "for" interprete c:\compartir\prueba.txt. Y como al ejecutar el script dentro del directorio puede usarse una referencia relativa (y no absoluta) al archivo prueba.txt, ya no se presenta el problema (2)
El parametro tokens=3 hace que "for" lea la tercer palaba de la primera linea del archivo prueba.txt. Y como la cantidad de lineas que contiene el archivo es una sola, el for se ejecuta una sola vez, obteniendo asi la letra de la unidad extraible (3)
El parametro /i permite olvidarse de si el nombre del volumen esta en mayusculas o minusculas.
Notas:
(1) para cambiar el nombre de volumen de un disco hay que hacer clic con botón derecho sobre el disco (en Mi Pc), luego propiedades y luego en la pestaña general, en el cuadro de texto que aparece arriba del todo (ver el cursor) se puede escribir el nombre de volumen.
(2) Es muy probable que un parámetro resuelva este comportamiento. La verdad es que hice un par de pruebas con parametros y simbolos, pero, antes que lidiar con las mañas de los comandos, es mas simple el corte por lo sano, siempre que funcione :-D
(3) Eso es asi siempre y cuando no haya mas de un dispositivo con el mismo nombre de volumen. Es esperable el buen criterio del tecnico al poner nombres de volumen a las unidades extraibles.
domingo 11 de septiembre de 2011
sábado 16 de abril de 2011
Cambiar directorio de almacenamiento de correo electronico a un pendrive o disco remoto
En Outlook:
Primero obtener la ruta del arhivo pst:
Herramientas, Opciones, Configuracion de correo, Archivos de datos.
Suele estar en C:\Users\USUARIO\AppData\Local\Microsoft\Outlook\Outlook1.pst
Mover Outlook1.pst a un directorio distinto, que tambien puede ser remoto. Iniciar Outlook. Al no encontrar Outlook1.pst, pues fue movido, pide la nueva ruta. Se la indica y listo. Ya queda funcionando en la nueva ruta. Lo bueno del programa es que no hace como Outlook Express que, al no encontrar la ruta, automaticamente se configura en la ruta por defecto.
En Outlook Express:
Desde las opciones de configuracion no permite indicar un directorio de almacenamiento remoto o un pendrive.
Para forzarlo hay que modificar el registro:
HKEY_CURRENT_USER\Identities\{Identidad}\Software \Microsoft\Outlook
express\5.0" y modificar la clave "Store root"
En esa clave se indica la ruta local, remota, pendrive, etc. Simplemente se hace doble clic en dicha clave y se modifica la ruta actual por la deseada.
Luego se puede copiar el contenido (correos) desde la ruta original en la nueva ruta.
Si la ruta no esta disponible momento de iniciar el programa, este se configura en los valores por defecto y queda asi aunque luego se restaure la ruta.
Por eso conviene exportar la clave anterior para incorporarla cada vez que ocurra eso. Tambien se puede armar un script para iniciar el programa que incorpore automaticamente la entrada del registro.
Si la ruta no esta disponible momento de iniciar el programa, este se configura en los valores por defecto y queda asi aunque luego se restaure la ruta.
Por eso conviene exportar la clave anterior para incorporarla cada vez que ocurra eso. Tambien se puede armar un script para iniciar el programa que incorpore automaticamente la entrada del registro.
En Mozilla Thunderbird:
Herramientas, Configuracion de las cuentas, Configuracion del servidor, Directorio local:
Primero tomar nota de la ruta actual
Modificar la ruta, que puede ser local o remota.
Cerrar el programa y mover el contenido del directorio original al nuevo directorio.
Windows Mail:
No encontré como hacerlo. Creo que tiene que ver el hecho de que este programa guarda archivos del tipo eml, los cuales tienen propiedades especiales ntfs que no pueden guardarse en sistemas fat32, por ejemplo.
domingo 12 de diciembre de 2010
Samba: compartir un sistema ntfs en Ubuntu 10.10
Hay distintos escenarios:
Nota para todos los escenarios: Voy a utilizar la herramienta de Nautilus (clic derecho, opciones de comparticion) para compartir recursos, otra forma es modificar el archivo /etc/samba/smb.conf, pero aqui intento utilizar las herramientas provistas por Ubuntu 10.10
Escenario 1: Ubuntu 10.10 desktop y automunt.
Cuando se produce un automunt o desde el menu lugares, Ubuntu hace propietario del punto de montaje al usuario, y le asigna permisos de lectura
y escritura. Sin embargo los atributos para otros usuarios son nulos: -rw------- 1 sg sg
Si el sistema montado es ntfs, el volumen montado adopta los permisos y propietario que tenga el directorio utilizado como punto de montaje y no puede ser modificado luego con chmod ni chown, al menos al dia de hoy: http://es.wikipedia.org/wiki/NTFS-3G
Si se quiere compartir algun recurso en ese punto de montaje, es posible, pero solo será accesible remotamente con el mismo usuario que montó la particion.
Digamos que el usuario "sg" montó un disco extraible con formato ntfs, entonces podrá compartir algun directorio de ese volumen, pero solo sg podrá
accederlo remotamente.
El modo de hacerlo es agregar el usuario al sistema samba:
smbpasswd sg
El comando solicita la contraseña, la cual, no necesariamente, tiene que ser la del sistema linux, incluso puede quedar vacia.
Pude comprobar que, independientemente de la contraseña, si el usuario samba es el mismo que el usuario ubuntu, ubuntu lo acepta como el mismo usuario; con lo cual puede crear y modificar archivos.
Si necesito acceder remotamente con otro usuario, digamos "operador", ese ya es un problema pues, a pesar de que puedo crear el usuario en el sistema samba, no es posible cambiarle ni propietario ni atributos al volumen montado (ver mas arriba en negrita)
No encontré solucion para este escenario. Solo el usuario, sg en este caso, puede acceder remotamente.
Eso es un problema, ya que en una red en la que todos estan acostumbrados a acceder al recurso sin ingresar usuario y pass, ya que son "operador", se complica explicarle a cada uno que deberán ingresar el usuario sg para acceder al recurso.
Obviamente que no ocurre lo mismo con un directorio en sistema ext4 (ext3, etc), ya que linux sí permite asignar distintos propietarios y atributos al sistema de archivos nativo.
Escenario 2: Ubuntu 10.10 Desktop y montaje hecho por root desde consola o fstab:
Para resolver el problema del escenario 1 hice lo siguiente:
Como root creé un directorio de montaje llamado "Disco". Aqui el problema es que el propietario del recurso será root, pero lo resuelvo asignandole permisos totales para todos:
mkdir /media/Disco
chmod 777 /media/Disco/
Luego monté la particion ntfs:
mount /dev/sda4 -t ntfs-3g /media/Disco/
El parametro -t ntfs-3g puede obviarse pero en este caso lo dejo mas que nada para destacar el tipo de sistema que se esta montando.
Para automatizar el montaje desde fstab, hay que agregar la siguiente linea:
UUID=D82C26B52C268F16 /media/Disco ntfs-3g defaults
En donde el UUID se obtiene con el comando:
blkid /dev/sda4
El comando blkid esta explicado en el mismo fstab, bueno, al menos el fstab que trae ubuntu 10.10
Con esto, el sistema queda montado con permisos de lectura y escritura para cualquier usuario. Con lo que ahora tanto sg como operador y cualquier otro usuario, podran acceder remotamente y modificar libremente, siempre y cuando samba haya permitido el acceso.
Y justamente, aqui se presentó otro problema: Al ser propietario root del directorio utilizado como punto de montaje (/media/Disco), samba, por las politicas por defecto que tiene, no permitia compartir el recurso. El mensaje que da al intentar compartir es este:
La «red compartida» devolvió el error 255: net usershare add: cannot share path /media/VERBATIM/Public as we are restricted to only sharing directories we own.
Ask the administrator to add the line "usershare owner only = false"
to the [global] section of the smb.conf to allow this.
Por suerte, ademas del codigo de error, tambien da la solucion. Ojalá todo en Ubuntu o cualquier otro SO, fuera asi.
Solo bastó agregar la siguiente linea en la seccion [global] de /etc/samba/smb.conf:
usershare owner only = false
Y luego ejecutar:
restart smbd
Este ultimo comando, para mi fue una sorpresa, ya que estaba acostumbrado a hacer:
/etc/init.d/smbd restart
Por suerte, otra vez linux me auxilio, y no solo informó de un error al ejecutar ese comando, sino que sugirió el modo de hacerlo correctamente.
Escenario 3: El sistema del recurso a compartir es ext2, ext3, etc.
Bueno, aqui las cosas son simples. Ya mencioné que linux permite adaptar los permisos de estos recursos sin problemas.
Nota para todos los escenarios: Voy a utilizar la herramienta de Nautilus (clic derecho, opciones de comparticion) para compartir recursos, otra forma es modificar el archivo /etc/samba/smb.conf, pero aqui intento utilizar las herramientas provistas por Ubuntu 10.10
Escenario 1: Ubuntu 10.10 desktop y automunt.
Cuando se produce un automunt o desde el menu lugares, Ubuntu hace propietario del punto de montaje al usuario, y le asigna permisos de lectura
y escritura. Sin embargo los atributos para otros usuarios son nulos: -rw------- 1 sg sg
Si el sistema montado es ntfs, el volumen montado adopta los permisos y propietario que tenga el directorio utilizado como punto de montaje y no puede ser modificado luego con chmod ni chown, al menos al dia de hoy: http://es.wikipedia.org/wiki/NTFS-3G
Si se quiere compartir algun recurso en ese punto de montaje, es posible, pero solo será accesible remotamente con el mismo usuario que montó la particion.
Digamos que el usuario "sg" montó un disco extraible con formato ntfs, entonces podrá compartir algun directorio de ese volumen, pero solo sg podrá
accederlo remotamente.
El modo de hacerlo es agregar el usuario al sistema samba:
smbpasswd sg
El comando solicita la contraseña, la cual, no necesariamente, tiene que ser la del sistema linux, incluso puede quedar vacia.
Pude comprobar que, independientemente de la contraseña, si el usuario samba es el mismo que el usuario ubuntu, ubuntu lo acepta como el mismo usuario; con lo cual puede crear y modificar archivos.
Si necesito acceder remotamente con otro usuario, digamos "operador", ese ya es un problema pues, a pesar de que puedo crear el usuario en el sistema samba, no es posible cambiarle ni propietario ni atributos al volumen montado (ver mas arriba en negrita)
No encontré solucion para este escenario. Solo el usuario, sg en este caso, puede acceder remotamente.
Eso es un problema, ya que en una red en la que todos estan acostumbrados a acceder al recurso sin ingresar usuario y pass, ya que son "operador", se complica explicarle a cada uno que deberán ingresar el usuario sg para acceder al recurso.
Obviamente que no ocurre lo mismo con un directorio en sistema ext4 (ext3, etc), ya que linux sí permite asignar distintos propietarios y atributos al sistema de archivos nativo.
Escenario 2: Ubuntu 10.10 Desktop y montaje hecho por root desde consola o fstab:
Para resolver el problema del escenario 1 hice lo siguiente:
Como root creé un directorio de montaje llamado "Disco". Aqui el problema es que el propietario del recurso será root, pero lo resuelvo asignandole permisos totales para todos:
mkdir /media/Disco
chmod 777 /media/Disco/
Luego monté la particion ntfs:
mount /dev/sda4 -t ntfs-3g /media/Disco/
El parametro -t ntfs-3g puede obviarse pero en este caso lo dejo mas que nada para destacar el tipo de sistema que se esta montando.
Para automatizar el montaje desde fstab, hay que agregar la siguiente linea:
UUID=D82C26B52C268F16 /media/Disco ntfs-3g defaults
En donde el UUID se obtiene con el comando:
blkid /dev/sda4
El comando blkid esta explicado en el mismo fstab, bueno, al menos el fstab que trae ubuntu 10.10
Con esto, el sistema queda montado con permisos de lectura y escritura para cualquier usuario. Con lo que ahora tanto sg como operador y cualquier otro usuario, podran acceder remotamente y modificar libremente, siempre y cuando samba haya permitido el acceso.
Y justamente, aqui se presentó otro problema: Al ser propietario root del directorio utilizado como punto de montaje (/media/Disco), samba, por las politicas por defecto que tiene, no permitia compartir el recurso. El mensaje que da al intentar compartir es este:
La «red compartida» devolvió el error 255: net usershare add: cannot share path /media/VERBATIM/Public as we are restricted to only sharing directories we own.
Ask the administrator to add the line "usershare owner only = false"
to the [global] section of the smb.conf to allow this.
Por suerte, ademas del codigo de error, tambien da la solucion. Ojalá todo en Ubuntu o cualquier otro SO, fuera asi.
Solo bastó agregar la siguiente linea en la seccion [global] de /etc/samba/smb.conf:
usershare owner only = false
Y luego ejecutar:
restart smbd
Este ultimo comando, para mi fue una sorpresa, ya que estaba acostumbrado a hacer:
/etc/init.d/smbd restart
Por suerte, otra vez linux me auxilio, y no solo informó de un error al ejecutar ese comando, sino que sugirió el modo de hacerlo correctamente.
Escenario 3: El sistema del recurso a compartir es ext2, ext3, etc.
Bueno, aqui las cosas son simples. Ya mencioné que linux permite adaptar los permisos de estos recursos sin problemas.
jueves 9 de diciembre de 2010
Bug del Modo protegido de Internet Explorer 8
El modo protegido de internet explorer 8 solo funciona con sistemas operativos Windows Vista o versiones superiores.
Basicamente sirve para dar seguridad contra las vulnerabilidades. O sea, uno puede tener una vulnerabilidad pero el modo protegido evita que un codigo dañino pueda ejecutarse en nuestro equipo, sin importar la vulnerabilidad que se este aprovechando.
Me ocurrió que si intentaba imprimir una pagina web a un archivo, digamos, por ejemplo, mediante la impresora virtual tinypdf, el documento no se guardaba como era de esperar.
Sin embargo, al intentar imprimir nuevamente, el asistente para guardar el archivo, dejaba ver el archivo anterior "perdido". O sea, el archivo estaba pero no estaba. El unico medio para visualizarlo era el asistente para imprimir de IE8.
El archivo existia pero no era visible, por ningun medio, en el directorio en cuestion.
La solucion:
El modo protegido crea un directorio virtual ubicado en:
C:\Users\Usuario\AppData\Local\Microsoft\Windows\Temporary Internet Files\Virtualized\
Con lo que, los archivos que se pretendan guardar en c:\users\Usuario\Desktop
Se guardan en primera instancia en :
......\Virtualized\C\Users\Usuario\Desktop
Luego, si se considera segura la transaccion, se guardarán en la ruta "real"
En el caso de una impresión mediante tinypdf, el proceso se trunca y el resultado final es que no se guarda el documento.
Ahora ya sabemos en donde buscar documentos perdidos a causa del modo protegido.
Una solución para evitar contratiempos es desactivar el modo protegido, a nuestro riesgo.
Gracias a José Perez que me ayudó a encontrar el maldito archivo "fantasma".
martes 17 de agosto de 2010
Cliente windows vista o seven no imprime bien en servidor de impresion linux
Le ocurrio a un amigo luego de instalar ubuntu 10.04 y compartir una impresora. Al instalar los clientes windows, aquellos cuyo sistema operativo es windows vista o seven, tienen problemas para imprimir.
Nos acordamos de que samba puede tener problemas con la encriptacion NTLMv2 y nos preguntabamos si la solucion no estaría en desactivar esa encriptacion en las negociaciones de sesiones smb.
La explicacion esta aqui: http://multingles.net/docs/jmt/wvsmb.html
En ese articulo se indica cómo modificar las politicas de windows para desactivar esa encriptacion. Incluso presenta una solucion sobre como modificar las politicas en aquellos sistemas que no cuentan con gpedit (ms siempre esta pensando en como joderle la vida al usuario starter).
Mi amigo fue un poco mas lejos y encontró cuales claves hay que modificar para cambiar esas politicas, y con eso resolver el problema. Al menos el problema de la encriptacion que describe el articulo de arriba.
Esas claves son:
HK_Local_Machine\System\CurrentControlSet\control\Lsa DWORD "LmCompatibilityLeveL" = 0
HK_Local_Machine\System\CurrentControlSet\control\Lsa\MSV1_0 Dword "NtLmMinClientxxxx" = 0x0000
"NtLmMinServer=" 0x0000
Luego de ese cambio, no solo se resolvio el problema de inicio de sesion, sino que, hasta el momento, los clientes windows vista y seven, imprimen sin problemas.
Gracias José!
Nos acordamos de que samba puede tener problemas con la encriptacion NTLMv2 y nos preguntabamos si la solucion no estaría en desactivar esa encriptacion en las negociaciones de sesiones smb.
La explicacion esta aqui: http://multingles.net/docs/jmt/wvsmb.html
En ese articulo se indica cómo modificar las politicas de windows para desactivar esa encriptacion. Incluso presenta una solucion sobre como modificar las politicas en aquellos sistemas que no cuentan con gpedit (ms siempre esta pensando en como joderle la vida al usuario starter).
Mi amigo fue un poco mas lejos y encontró cuales claves hay que modificar para cambiar esas politicas, y con eso resolver el problema. Al menos el problema de la encriptacion que describe el articulo de arriba.
Esas claves son:
HK_Local_Machine\System\CurrentControlSet\control\Lsa DWORD "LmCompatibilityLeveL" = 0
HK_Local_Machine\System\CurrentControlSet\control\Lsa\MSV1_0 Dword "NtLmMinClientxxxx" = 0x0000
"NtLmMinServer=" 0x0000
Luego de ese cambio, no solo se resolvio el problema de inicio de sesion, sino que, hasta el momento, los clientes windows vista y seven, imprimen sin problemas.
Gracias José!
domingo 18 de julio de 2010
Ubuntu: Crear un acceso a un recurso remoto compartido por windows
El siguiente texto supone que el recurso remoto se encuentra en //192.168.1.102/compartido y dicho recurso no esta protegido por contraseña.
El modo de conectarse a un recurso remoto utilizando nautilus es:
En la barra de direccion escribir, por ejemplo: smb://192.168.1.102/compartido
Tambien puede utilizarse el asistente: archivo, conectar con el servidor, tipo de servicio, compartido por windows
Luego, si uno quiere automatizar el asunto podria crear una entrada en el archivo
/etc/fstab:
//192.168.1.102/compartido /media/compartido cifs users,rw,auto,guest 0 0
Luego de eso, como uno de los parametros de mount es "users", se le permite al usuario montar y desmontar el recurso.
A partir de aqui comienza una serie de problemas.
El primero con el que me encontré:
En algunos sistemas, el solo hecho de agregar esa linea en fstab hace que el recurso se vea en 'Equipo' (computer:///)
Entonces con solo hacer doble clic se monta, con clic derecho tambien se monta o se desmonta. En fin todo muy bonito.
En otros sistemas no encontré cómo hacer que el recurso aparezca en computer:///
La solucion que encontre fue simple: crear un lanzador con la siguiente linea de comando:
mount /media/compartido
Eso resolvio el primer problema.
Obviamente, todo esto fue pensando en el operador y en no tener que darle instrucciones cripticas para un operarador inexperto.
El segundo:
Con el recurso montado de ese modo las cosas parecen funcionar bien, hasta que uno se topa con este bug:
http://www.mail-archive.com/ubuntu-bugs@lists.ubuntu.com/msg1272315.html
Basicamente, cuando, desde nautilus, se intenta reemplazar un archivo con otro del mismo nombre, no nos deja. Tampoco se pueden modificar archivos con gedit ya que informa de un error impidiendo la modificacion.
Ese error en español es:
"Error inesperado: Archivo de texto en uso"
Y en ingles:
“Unexpected Error: Text file busy”
El error de nautilus al intentar reemplazar un archivo del mismo nombre es:
En español:
"Error al renombrar el archivo temporal: Archivo de texto en uso"
Y en ingles:
“Error while renaming temporary file: Text file busy”
Al parecer son los unicos dos problemas. Abrir archivos de open office no trae problemas, por ejemplo.
Sin embargo, el operador no sabe de bugs, ni le interesan, ni quiere lidiar con ellos.
La solucion que encontre fue la siguiente:
Todo es tan simple como crear un lanzador con la siguiente linea de comandos:
nautilus smb://192.168.1.102/compartido
El modo de conectarse a un recurso remoto utilizando nautilus es:
En la barra de direccion escribir, por ejemplo: smb://192.168.1.102/compartido
Tambien puede utilizarse el asistente: archivo, conectar con el servidor, tipo de servicio, compartido por windows
Luego, si uno quiere automatizar el asunto podria crear una entrada en el archivo
/etc/fstab:
//192.168.1.102/compartido /media/compartido cifs users,rw,auto,guest 0 0
Luego de eso, como uno de los parametros de mount es "users", se le permite al usuario montar y desmontar el recurso.
A partir de aqui comienza una serie de problemas.
El primero con el que me encontré:
En algunos sistemas, el solo hecho de agregar esa linea en fstab hace que el recurso se vea en 'Equipo' (computer:///)
Entonces con solo hacer doble clic se monta, con clic derecho tambien se monta o se desmonta. En fin todo muy bonito.
En otros sistemas no encontré cómo hacer que el recurso aparezca en computer:///
La solucion que encontre fue simple: crear un lanzador con la siguiente linea de comando:
mount /media/compartido
Eso resolvio el primer problema.
Obviamente, todo esto fue pensando en el operador y en no tener que darle instrucciones cripticas para un operarador inexperto.
El segundo:
Con el recurso montado de ese modo las cosas parecen funcionar bien, hasta que uno se topa con este bug:
http://www.mail-archive.com/ubuntu-bugs@lists.ubuntu.com/msg1272315.html
Basicamente, cuando, desde nautilus, se intenta reemplazar un archivo con otro del mismo nombre, no nos deja. Tampoco se pueden modificar archivos con gedit ya que informa de un error impidiendo la modificacion.
Ese error en español es:
"Error inesperado: Archivo de texto en uso"
Y en ingles:
“Unexpected Error: Text file busy”
El error de nautilus al intentar reemplazar un archivo del mismo nombre es:
En español:
"Error al renombrar el archivo temporal: Archivo de texto en uso"
Y en ingles:
“Error while renaming temporary file: Text file busy”
Al parecer son los unicos dos problemas. Abrir archivos de open office no trae problemas, por ejemplo.
Sin embargo, el operador no sabe de bugs, ni le interesan, ni quiere lidiar con ellos.
La solucion que encontre fue la siguiente:
Todo es tan simple como crear un lanzador con la siguiente linea de comandos:
nautilus smb://192.168.1.102/compartido
miércoles 23 de junio de 2010
Cambiar el puerto de escucha del escritorio remoto de Windows
Sí, sí. Eso esta por todos lados. Incluso MS explica cómo hacerlo:
http://support.microsoft.com/kb/306759/es
El problema es qué hacer si luego de cambiar el puerto no funciona?
Lo que hay que hacer es desactivar el acceso remoto y luego volver a activarlo.
O mejor, desactivar el acceso remoto, aplicar el cambio en el registro y luego volver a activarlo. Los pillos de ms no aclaran eso y me hicieron perder un par de minutillos.
Para activar/desactivar: Panel de control, Sistema, Remoto.
Bueno, y por si llegaste hasta aqui con la esperanza de ver qué cambios hay que hacer y ni ganas de viajar hasta ms, aqui va:
http://support.microsoft.com/kb/306759/es
El problema es qué hacer si luego de cambiar el puerto no funciona?
Lo que hay que hacer es desactivar el acceso remoto y luego volver a activarlo.
O mejor, desactivar el acceso remoto, aplicar el cambio en el registro y luego volver a activarlo. Los pillos de ms no aclaran eso y me hicieron perder un par de minutillos.
Para activar/desactivar: Panel de control, Sistema, Remoto.
Bueno, y por si llegaste hasta aqui con la esperanza de ver qué cambios hay que hacer y ni ganas de viajar hasta ms, aqui va:
- Inicie el Editor del Registro (Regedt32.exe).
- Busque la siguiente clave del Registro: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\TerminalServer\WinStations\RDP-Tcp\PortNumber
- En el menú Edición, haga clic en Modificar, Decimal, escriba el nuevo número de puerto y, después, haga clic en Aceptar.
- Salga del Editor del Registro.
Suscribirse a:
Entradas (Atom)
