Pokazywanie postów oznaczonych etykietą Windows Server 2012. Pokaż wszystkie posty
Pokazywanie postów oznaczonych etykietą Windows Server 2012. Pokaż wszystkie posty

22 października 2015

Wyłączanie chwilowe Direct Access na kliencie

Dawno nie pisałem, ale nadmiar pracy i testy nowych technologii, które miały status NDA trochę mi to utrudniały. Ale żeby nie zapomnieć chciałem dodać jedną informację o używaniu Direct Access. Jest to świetna technologia, człowiek cały czas podłączony jest do lokalnych zasobów firmowych, może używać krótkich nazw serwisów intranetowych niezależnie od tego, gdzie jest podpięty. Jednak czasem bywa to uciążliwe, zwłaszcza gdy chcemy sprawdzić poprawność publikowanych usług od strony Internetu. Do wyłączenia Direct Accessa niezbędne jest zatrzymanie dwóch usług systemowych – asystenta usług sieciowych i IP Helpera, co w normalnych warunkach wymaga odpalenia konsoli services.msc, znalezienia odpowiednich usług i ich zatrzymanie. Oczywiście odwrócenie konfiguracji wymaga włączenia tych usług lub restart komputera. Dużo szybciej jest przygotować sobie skrypt powershell, który możemy “prawokliknąć” i wybrać opcję “Run with powershell”. Cały problem polega na tym, że zatrzymanie usług wymaga odpalenia skryptu z wyższymi uprawnieniami (nieszczęsny UAC). Pomyślałem sobie, że najprościej włączyć eskalację uprawnień wewnątrz skryptu, co też uczyniłem, wykorzystując konstrukcję opisaną na blogu Bila Armstronga - http://blogs.msdn.com/b/virtual_pc_guy/archive/2010/09/23/a-self-elevating-powershell-script.aspx:

#
# script to stop Direct Access on user computer
# if user has local administrator permission
#

# Get the ID and security principal of the current user account
$myWindowsID=[System.Security.Principal.WindowsIdentity]::GetCurrent()
$myWindowsPrincipal=new-object System.Security.Principal.WindowsPrincipal($myWindowsID)
 
# Get the security principal for the Administrator role
$adminRole=[System.Security.Principal.WindowsBuiltInRole]::Administrator
 
# Check to see if we are currently running "as Administrator"
if ($myWindowsPrincipal.IsInRole($adminRole))
    {
    # We are running "as Administrator" - so change the title and background color to indicate this
    $Host.UI.RawUI.WindowTitle = $myInvocation.MyCommand.Definition + "(Elevated)"
    $Host.UI.RawUI.BackgroundColor = "DarkBlue"
    clear-host
    }
else
    {
    # We are not running "as Administrator" - so relaunch as administrator
   
    # Create a new process object that starts PowerShell
    $newProcess = new-object System.Diagnostics.ProcessStartInfo "PowerShell";
   
    # Specify the current script path and name as a parameter
    $newProcess.Arguments = $myInvocation.MyCommand.Definition;
   
    # Indicate that the process should be elevated
    $newProcess.Verb = "runas";
   
    # Start the new process
    [System.Diagnostics.Process]::Start($newProcess);
   
    # Exit from the current, unelevated, process
    exit
    }
 
 
stop-service NCASvc
stop-service iphlpsvc

Na podobnej zasadzie można oczywiście realizować inne operacje cykliczne operacje, np. zmiany adresu IP.

15 listopada 2013

Windows – ile wynosi czas życia rekordów w DNS?

Ostatnio zmieniałem ustawienia DNS na pewnym serwerze i zauważyłem pewne rozbieżności w czasie życia rekordów DNS. Zweryfikowałem ten temat, przy okazji odświeżając sobie wiedzę dotyczącą ustawień DNS w różnych wersjach Windows. Tak naprawdę zmiany pomiędzy kolejnymi wersjami nie są duże. Pierwszym parametrem, jaki możemy ustawić, jest domyślny czas życia rekordu dla danej strefy DNS, ustawiając odpowiednią wartość w rekordzie opisującym strefę (SOA). Domyślnie jest to jedna godzina, co łatwo możemy zmienić z konsoli graficznej - HOW TO: Modify Time to Live on Domain Name System Records.

image

Jednakże ustawienie te, jak łatwo się przekonać weryfikując właściwości poszczególnych rekordów, dotyczy wyłącznie obiektów dodawanych statycznie przez administratora. Dla rekordów tworzonych dynamicznie wygląda to zupełnie inaczej - rekordy A i PTR rejestrowane przez usługę Net Logon (np. rekordy SRV usług udostępnianych przez kontrolery domeny) mają ustawiany czas życia (TTL) o wartości 10 minut. Rekordy rejestrowane przez usługę DHCP Client domyślnie mają TTL ustawiany na 15 minut. Rekordy tworzone przez usługę DNS Server service (w większości wypadków są to rekordy zgłaszane przez serwery/stacje robocze poprzez usługę DNS Client) mają domyślnie ustawiony TTL na 20 minut. I takich rekordów, w domenie ze stacjami roboczymi Windows 7/8 jest najwięcej. Oczywiście w większości wypadków takie ustawienia są wystarczające, jednak czasami chcemy zmienić domyślny czas dla niektórych hostów, np. dla wybranych serwerów. Można to zrobić poprzez klucz w rejestrze na wybranych hoście:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\DefaultRegistrationTTL

Klucz jest typu REG_DWORD i domyślnie ma wartość 0x4B0 (1,200 sekund = 20 minut). Możemy to zmienić na dowolną wartość z zakresu: 0x0 - 0xFFFFFFFF sekund – np. 0xE10 (1 godzina), a nawet 0x15180 (24 godziny), choć jak dla mnie to już lekka przesada. Więcej ustawień modyfikujących parametry ustawień klienta DNS można znaleźć w artykule KB 246804.

Możemy to również zmienić poprzez GPO:

DNSTTL

23 października 2013

Problemy z kartami sieciowymi w serwerach nie tylko Exchange

Kilka dni temu pojawiły się informacje serwisu VMware o problemach z kartami sieciowymi typu e1000e na platformie ESXi 5.0 lub 5.1 dla systemu Windows 2012 (ten sam problem dotyczy Windows 2012R2). Problem może powodować utratę danych przesyłanych między serwerami (np. w ramach DAG-a). Zalecana jest zmiana typu karty sieciowej na e1000 lub vmxnet3. Kolejny problem związany z domyślnym ustawieniem kart sieciowych wskazał Mike O'Neill na blogu zespołu produktowego Exchange – domyślnie włączone ustawienie, zezwalające serwerowi na wyłączenie karty sieciowej w celu zmniejszenia zużycia energii powoduje zanik heartbeatu między węzłami clustra (czyli serwerami w ramach DAG) i nieplanowane przełączenia węzłów w clustrze, nawet pomiędzy różnymi datacenter. Żeby tego uniknąć należy odkliknąć checkbox w ustawieniach karty sieciowej serwera/serwerów, jak na poniższym rysunku, można również użyć do tego skryptu, opublikowanego w TechNet Gallery. Można również użyć GPO i klucza w rejestrze, któy odpowiada za to ustawienie, zgodnie z artykułem http://support.microsoft.com/kb/2740020.

25 maja 2013

Współpraca Office365 z Windows Server 2012

Kilka tygodni temu sprawdzałem możliwości współpracy modelu hybrydowego dla organizacji korzystającej z Offce365 i zauważyłem, że większość dokumentacji mówi wyłącznie o DirSync-u na systemie nie nowszym niż Windows 2008R2 i ADFS 2.0 RTW (który nie jest wspierany na platformie Windows 2012) do obsługi Single SignOn. Jednak dzisiaj znalazłem informacje, wskazujące na możliwość wykorzystania Windows 2012 Standard lub Datacenter zarówno jako serwer DirSynca, jak i dla Single SignOn. W tym drugim przypadku należy pamiętać o zainstalowaniu w Windows 2012 systemowej roli ADFS (ADFS 2.1) oraz pobraniu Windows Azure AD Module for Windows PowerShell. Mam nadzieję, że w najbliższych dniach zweryfikuję to własnoręcznie.Niestety realizawana od kilku miesięcy przebudowa portalu Microsoft Technet, zwłaszcza działu Downloads, nie ułątwia znalezieniu odpowiednich informacji. Warto jednak zajrzeć na stronę Wiki technologii Azure, gdzie jest podlinkowanych dużo informacji na temat zarówno synchronizacji jak i SSO.

07 marca 2013

Konfigurowanie ustawień sesji RDP w Remote Desktop Services 2012

Ładnych kilka miesięcy minęło od premiery Windows 2012, a dokumentacja do niektórych opcji niestety nadal nie jest zbyt jasno napisana. Zarządzanie i konfiguracja usług RDS realizowane jest poprzez specjalną konsolkę w Server Managerze – Remote Desktop Management Services (RDMS) znacznie różni się od konsol MMC dostępnych w Windows 2008 i 2008R2, jak widać na poniższym rysunku.

RDS-console

Część zadań realizuje się prościej (kreatory to konfigurowania serwerów w farmie, kreatory publikowania aplikacji). Jednak jak wykonać bardziej zaawansowane zadania? Oczywiście w powłoce PowerShell Uśmiech.

Jednym ze standardowych ćwiczeń na szkoleniu z Remote Desktop Services jest skonfigurowanie aplikacji, do wyświetlenia na dwóch monitorach. W tym celu trzeba pliku z definicją parametrów połączenia (.rdp), w dowolnym edytorze dodać linię o wartości

span monitors:i:1

W Windows 2008R2 można również wejść w zakładkę Custom RDP Settings ustawień wdrożeniowych RemoteApp i wpisać potrzebne właściwości w kolejnych wierszach pola edycyjnego:

CustomRDPSettings

W Windows 2012 zamiast tego możemy użyć komendy Set-RDSessionCollectionConfiguration. W tym celu musimy jednak uruchomić PowerShella w trybie administratora i zaimportować moduł RemoteDesktopService. Żeby dla kolekcji aplikacji ustawić rozciąganie aplikacji na dwa monitory musimy użyć komendy w postaci:

Set-RDSessionCollectionConfiguration -CollectionName app1-col -CustomRdpProperty "span monitors:i:1"

Jednak ponowne użycie tej komendy z inną opcją, zamaże poprzedni wpis – trzeba użyć wszystkich niestandardowych atrybutów jednocześnie, oddzielając je znacznikiem `n. Jeżeli zatem chcemy dodać parametr, pozwalający na mapowanie do środowiska zdalnej sesji tylko lokalne dyski C: i E: musimy wykonać komendę:

Set-RDSessionCollectionConfiguration –CollectionName app1-col "drivestoredirect:s:C:;E:; `n span monitor:i:1"

Więcej informacji, jakie opcje można skonfigurować w ten sposób można znaleźć tutaj - RDP Settings for Remote Desktop Services in Windows Server 2008 R2. Co ciekawe, opcji pozwalającej mapować w sesji tylko wybrane dyski, na powyższej liście nie ma. Ustawienia dla RDS w Windows 2012 nie zostały jeszcze opublikowane, ale te z Windows 2008R2 działają. Lista cmdletów do zarządzania RDS w Windows 2012 opisana jest, niestety dość ogólnie w dokumentacji na stronie Technet.

12 października 2012

MCSE – Server Infrastructure Windows 2012

Tydzień temu zdawałem egzamin 70-411, którego nie zdążyłem zdać w becie, a dzisiaj kolejna niespodzianka – po powrocie z wyjazdu czekał na mnie nowy certyfikat – nie tylko MCSA, ale również MCSE – pojawiły się wyniki egzaminów 71-414 i 71-415, które zdawałem w sierpniu.

MCSEServerInfrastructure2012

26 września 2012

Exchange 2010 Service Pack 3 oficjalnie zapowiedziany

Przy okazji organizowanych przez siebie dużych konferencji Microsoft ogłasza premiery lub istotne zmiany w swoich produktach. I tak podczas reaktywowawanej po 10 latach konferencji MEC (Microsoft Exchange Conference 2012) w Orlando Microsoft ogłosił wypuszczenie w pierwszej połowie 2013 roku pakietu Service Pack 3 do Exchange 2012, który będzie niezbędny w przypadku wdrażania Exchange 2013 w istniejącym środowisku Exchange 2010, będzie również pozwalał na instalację Exchange 2010 na platformie Windows 2012. Oczywiście zgodnie z polityką aktualizowania systemu, nowy Service Pack będzie zawierał wszystkie poprawki do serwera Exchange 2010, jakie ukażą się do momentu wydania nowego Service Packa.

Dwa tygodnie temu zespół Exchange ogłosił prace zmierzające do objęcia wsparciem dla Windows 2012 serwera Exchange 2010 SP2, tak że prawdopodobnie będzie jeszcze przed SP3 wydany Rollup, który na to pozwoli, ale niestety termin publikacji takiej poprawki nie jest jeszcze znany.

Announcing Exchange 2010 Service Pack 3 - Exchange Team Blog