Microsoft BYOD Test Lab Guides Updated | Windows content from Windows IT Pro

Microsoft BYOD Test Lab Guides Updated | Windows content from Windows IT Pro

Podstawowa konfiguracja interfejsu sieciowego IP , MASKA , BRAMA poprzez CMD

netsh interface ip set address name="Local Area Connection" source=static addr=192.168.1.41 mask=255.255.255.0 gateway=192.168.1.2 gwmetric=0

Zdalne dodanie komputera do domeny / "netdom.exe"

Sprawdzone działa:

NETDOM JOIN serwer /Domain:domena.local /UserD:Administrator /PasswordD:* /UserO:Administrator /PasswordO:* /ReBoot:30

Na podstawie:
Force a remote machine to join domain | Plain Tutorials

Funkcje narzędzia Sysprep i znane problemy

http://support.microsoft.com/kb/928386/pl

Steve O'Donnell & Brian Madden - Dlaczego VDI jest zawodne... ?

Steve O'Donnell & Brian Madden - Why VDI projects fail on Vimeo

Brak mozliwości podłączenia przez RDP z laptopa do Connection Broker ( VM ) - wss.geekclub.pl

Forum – temat: Brak mozliwości podłączenia przez RDP z laptopa do Connection Broker ( VM ) - wss.geekclub.pl

Problem:

Witam.

Tworze sobie małe srodowisko testowe z Remote Desktop Services w celu udostępniania uzytkownikom wirtualnych pulpitów do wirtualnych maszyn.

Moja konfiguracja:

1. HOST ( serwer fizyczny) Windows Server 2008 R2 z rolą Hyper-V

2. VM 1 - Kontroler Domeny / Windows Server 2008 R2

3. VM 2 - Connection Broker / Windows Server 2008 R2

Wzorowałem się na tym przykładzie

http://www.microsoft.com/en-us/showcase/details.aspx?uuid=fbaf6f70-45fd-4c81-be70-6d276d54776b

W kazdym badz razie konfiguracja stoi na osobnym komputerze i chcialem najprosciej w swiecie łączyc sie do każdej maszyny przez RDP z osobnego laptopa ( aby z niego zarządzac srodowiskiem ). Do kazdej maszyny moge z wyjątkiem VM gdzie mam role Connection Broker. 

1. Podaje adres IP 

2. Prosi mnie o usera i haslo

3. Informuje mnie standardowo o niewaznym certufikacie ( czyli juz jakies polaczenie jest )

4. Następnie - Wyskakuje mi komunikat:

Remote desktop connection could not find the destination computer. This is happen if the computer name is incorrect or the computer is not yet registered with sesion broker.

Try connection again, or contact to your network administrator.

Rozwiązanie:

Z uwagi na to iż Connection Broker działa głównie ( z tego co sie dowiaduje ) jako m.in. np przekierowaniu do pulpitu lub virtualnej maszyny okreslonego użytkownika to próbowałem zalogowac sie jako Administrator domeny który nie ma domyslnie przypisanego żadnej maszyny wirtualnej. I dlatego taki komunikat. 

Uzyłem jednak polecenia cmd-line i polączyłem sie z sesją konsolową:

mstsc /v: \admin

Po tej komendzie nastąpiło poprawne połączenie do serwera skąd mogłem juz nim zarządzać.

Co ciekawe po przypisaniu virtualnej maszyny do administratora domeny i próbie ponownego polączenia przez RDP z GUI lub cmd

mstsc /v: nastąpiło także poprawne połączenie z wybraną wczesniej wirtualną maszyną.

Napkin Sketch of Secure Anywhere Access with RDS

Author: Dana Epp - Microsoft MVP, Enterprise and Developer Security

Recently, I had a discussion with the IT administrator of a midsize business about the value of working remotely. He was looking to migrate away from his current Terminal Services on an aged Windows Server 2003 infrastructure that supports a mobile workforce of more than 100 users. During our conversation, it was clear to me that he wasn’t fully aware of the latest advancements to Terminal Services.

Terminal Services has undergone a name change, and, as a core technology in the Windows Server 2008 R2 operating system, it’s now called Remote Desktop Services. Along with the new name have come a number of new features that expand functionality.  To clear things up about RDS, I quickly drew a simple diagram for him on the back of a napkin (see Figure 1).

Figure 1.

RDS has five main components—Remote Desktop Web Access, Remote Desktop Gateway, Remote Desktop Session Host, Remote Desktop Virtualization Host, and Remote Desktop Connection Broker (abbreviated in the napkin sketch as RDWA, RDG, RDSH, RDVH, and RDCB, respectively)—each of which provides different functionality. Together with additional RDS features, these core components create a framework that allows for secure anywhere access to applications, remote desktops, and even virtual desktops.

Let’s explore these core components, and how each one can help deliver secure anywhere access in a Windows world.

From a user’s perspective, the easiest way to access resources is through a webpage. The user can reach a published URL on Internet Information Services (IIS) provided by Remote Desktop Web Access (RD Web Access) in a secure manner via Secure Sockets Layer (SSL). This interface provides a rich web portal experience that makes published applications visible using the RemoteApp and Desktop Connection features. Normally, to reach this web portal  you simply point your browser to https://your.domain.com/rdweb. Once authenticated through domain credentials, users have links to the applications and desktops that they are authorized to access. This is all managed through an access control list (ACL), which limits what users are authorized to see and use.

The browser isn’t the only way that a user can connect. Using the Remote Desktop Gateway (RD Gateway) provides direct RDS connections, filtering requests based on policy decisions enforced by the Network Policy Server (NPS). Because the RD Gateway is on the edge of the network, the NPS uses two policies to control access:

• Remote Desktop Connection Authorization Policy (RD CAP) helps control who is authorized to connect through the RD Gateway server.
• Remote Desktop Resource Authorization Policy (RD RAP) helps control which resources a CAP-approved user is allowed to access through the RD Gateway server.

To connect to a RD Gateway server, all a user has to do is adjust the advanced settings in the Remote Desktop client to point to it (see Figure 2). And this can be done over SSL, which means it has a higher chance of success in limited environments in which standard Remote Desktop Protocol (RDP) or virtual private network (VPN) may not be allowed.

Figure 2.

Once users have connected, applications are hosted through the Remote Desktop Session Host (RD Session Host). This is the basis of how RDS works, loading applications and processing everything within the user’s session. It is even possible to load balance the architecture with multiple RD Session Host servers to address scalability, and to digitally sign applications with a certificate to provide trusted delivery to users.

 A new feature in the Windows Server 2008 R2 RD Session Host is the ability to use ACLs to manage which published applications a user is authorized to access. This capability allows you to refine least-privilege parameters to help provide secure remote access to line-of-business applications through Active Directory security groups or individual user names applied to the ACL.

With Hyper-V virtualization technology in Windows Server 2008 R2, you can setup a Remote Desktop Virtualization Host (RD Virtualization Host) to serve requests from desktops running on virtual machines (VMs). When a request comes in from a RD Session Host, the RD Virtualization Host spins up a target desktop if the VM is not already running. The pairing of the RD Session Host and the RD Virtualization Host is managed by Remote Desktop Connection Broker (RD Connection Broker).

RD Connection Broker is the management center access to virtual machines. It provides a unified experience for setting up access to applications and virtual desktops through the Remote Desktop Connection Manager (RD Connection Manager) console.  With the RD Connection Manager console, you can define which virtual desktops are dedicated to specific users, and which are in a pool of dynamically allocated VMs. RD Connection Manager allows you to further define RD Session Host servers, terminal servers, and RD Virtualization Host servers so you can deliver a consistent URL via RD Web Access for RemoteApp and virtual desktops.   

Ultimately, when a user connects to RD Web Access and clicks on an application or virtual desktop, the Remote Desktop Connection (RDC) client gets connection information streamed to it. If the user is working remotely, the client connects through the RD Gateway. If the user is onsite within the local LAN the client connects to the appropriate RD Session Host or RD Virtualization Host as determined by the RD Connection Broker. In both cases, the RD Connection Broker ensures that a client gets connected to the right resource in a secure manner.

With the use of a certificate, you can even digitally sign and provide single-sign on (SSO) so the user’s experience is streamlined while still delivering a higher level of security. If you need further identity assurance when accessing RD Web Access, you can use smartcards or third-party strong authentication solutions such as those provided with AuthAnvil from Scorpion Software or RSA SecurID.

Back to the napkin sketch: the IT administrator for whom I drew the architectural diagram was surprised by just how much RDS has progressed. The ability for staff to work securely and remotely while using Windows is here now. It’s built right into Windows Server 2008 R2. It is something the IT administrator is now checking out with the 120-day evaluation built in to Windows Server 2008 R2 for the RDS Licensing Server. You should check it out, too.

żródło: Napkin Sketch of Secure Anywhere Access with RDS

Remote Desktop can't find the computer -xxxx-. This might mean that -xxxx- does not belong to the specified network. Verify the computer name and domain that you are trying connect to.

Remote Desktop can't find the computer -xxxx-. This might mean that -xxxx- does not belong to the specified network. Verify the computer name and domain that you are trying connect to.

Problem który miałem podczas próby podłączenie się poprzez Remote Desktop Services komputerem niepodpiętym do domeny. W tym przypadku była to wirtualna maszyna jednak fizyczny laptop miał identyczny komunikat. Podpięcie do domeny umożliwiło poprawną prace.

Tworzenie wirtualnej maszyny z użyciem dysku różnicowego

Przygotowanie klienta Windows 7 do pracy jako VDI w pigułce / powershell

1. Sciągnij ten skrypt na maszyne windows 7 wpisując w wyszukiwarce google:
"configure microsoft vdi desktop vbscript" lub "configure microsoft vdi desktop powershell"
http://gallery.technet.microsoft.com/scriptcenter/bd2e02d0-efe7-4f89-84e5-7ad70f9a7bf0

2. Uruchom okno powershela i wpisz
Get-ExecutionPolicy
Zapewne wyswietli sie napis "Restricted"
Wpisz: Set-ExecutionPolicy unrestricted
Podpowiedz: http://superuser.com/questions/106360/how-to-enable-execution-of-powershell-scripts

3. Uruchom skrypt wpisujac jego nazwe:  skrypt.ps1. Następnie nazwe serwera gdzie przechowywane są wirtualne maszyny w postaci "domena\nazwa serwera"

Jesli jestes połączony przez RDP do klienta zapewne utracisz polaczenie. Połącz sie ponownie.

Powinno być OK :)

Scripting for Remote Desktop Services

Skrypty powershela w zastosowaniu do Remote Desktop Services.

Scripting for Remote Desktop Services - full site

Remote Desktop Services Scripts

Browse the Script Gallery for Remote Desktop Services scripts

• Remote Desktop Gateway
• Remote Desktop Licensing
• RDS Application Compatibility
• RDS Host Farm Management
• Virtual Desktop Infrastructure (VDI)
• VDI Monitoring Sessions
• VDI Troubleshooting and Verification
• VDI Usage reporting
• VDI Virtual Machine Creation and Configuration
• VDI Virtual Machine Assignment Management
• Other VDI Scripts

Networking - ciekawostki / konfiguracja stosu TCP

Problem:

Wolne nawiązywanie połączenia przez RDP do hosta.
Bardzo powolne ładowanie systemu.
Bardzo długie włączanie komputera HOSTA wirtualizacji który miał się połączyć z kontrolerem domeny będący zainstalowany w maszynie wirtualnej na tym hoscie.

Konfiguracja:
Host - Windows 2008 R2 Enterprise + Hyper-V

Rozwiązanie:
http://www.kuskaya.info/2012/02/28/how-to-troubleshoot-the-terminal-server-security-layer-detected-an-error-in-the-protocol-stream-and-has-disconnected-the-client-client-ip-and-the-rdp-protocol-component-x/

Powiązane:
http://support.microsoft.com/kb/951037
http://support.microsoft.com/kb/912222/pl
http://technet.microsoft.com/en-us/network/dd277646.aspx