Jauramine SCCM Compliance Settings’itega (vol. 2)

Vahepeal lisandus eelmisele tegutsemisele veel informatsiooni.

Kui sealtoodud fiksid üldiselt lahendavad probleemid, siis hetkeks on välja koorunud üks konkreetne OS – kus ei aita ei ussi-ega-püssirohi.

Nimelt, Windows Server 2008 64-bit SP2.  Visalt tuleb evaluaatori vastus “Non-Compliant”. Sul võib olla WinRM 2 või 3, SCCM kliendi versioon misiganes, kuid tulemust pole.

Hetkelise (näiva) lahenduse annab WMI komponentide uuesti registreerimine , repositooriumi repair ja teised sarnased tegevused, kuid peale lühikest olukorra settimist on tulemus vana.

 

Tundub, et TÄPSELT sama viga on teadvustatud Windows Serve 2003/XP korral ja isegi vastav KB üllitatud (http://support.microsoft.com/kb/923850) kuid samasugust Windows 2008 / Vista põlvkonnale pole minul õnnestunud leida. Kuigi selle artiklis toodud dll’i versioonist midagi ei sõltu.

Nii et siin ka üks põhjus selle põlvkonna OS’idest loobumiseks.

Windows serveri aktiveerimine.

image

 

Tavalises keskkonnas (Active Directory ja suhteliselt avatud sisevõrk) on Windows Serveri aktiveerimine imelihtne, eeldusel et Sul (sinu firmal, kliendil) on Microsoftiga hulgilitsensi leping.

1. Installeeri  KMS (ja aktiveeri see kindlasti KMS võtmega).

2. Kirjelda KMS teenuskirje (SRV) DNS’is.

Service: _VLMCS

Protocol: _tcp

Priority: 0

Weight: 0

Port: 1688

ja defineeri hosti nimi.

Kui aktiveerimist vajav server kuulub samasse AD domeeni, siis leitakse kirje automaatselt DNS päringuga. Kui domeene/metsi on mitmeid, kuid soovid sama KMS’i kasutada, siis defineeri vastvad SRV kirjed igas DNS tsoonis.

Tsipa keerulisemaks läheb olukord juhul, kui server pole domeeni liidetud ja/või asub tulemüüride taga.

Alati on võimalik server aktiveerida lihtsama vastupanu teed minnes – ehk kasutada MAK (multiple aktivation key) või suhelda Microsofti toetelefoniga.

Laisa inimesena otsustasin KMS lahenduse tööle ajada. Selleks:

1. käivita (Elevated õigustes) CMD ja käsuta

cscript c:\windows\system32\slmgr.vbs –skms sinuKMS.server.fqdn[:port]

kui nimelahendus töötab, kasuta nime, kui ei, võid kasutada IP’d või nime/IP hosts faili kirjutada. Kui kasutada vaikimisi porti (1688) pole porti defineerida vaja.

Väljund peaks olema:
Microsoft (R) Windows Script Host Version 5.8
Copyright (C) Microsoft Corporation. All rights reserved.

Key Management Service machine name set to sinuKMS.server.fqdn successfully.

2. Hoolitse, et oleks avatud TCP port 1688 serveri ja sinuKMSserveri vahel. Proovi kasvõi telnet sinuKMS.server.FQDN 1688

(NB! Telnet klient on alates Windows 2008’st eraldi installimist vajav Featuur).

Kui kasutad serveris Windowsi või mingit muud tulemüüri siis võib-olla vajadus ka sinna vastva reegel lisada. Näiteks Forefront TMG serveri puhul on enamus liiklust vaikimisi keelatud (mõningane hulk haldus porte on lubatud, kuid mitte aktiveerimiseks vajalik)

 

3. käsuta samas CMD promptis

cscript C:\Windows\System32\slmgr.vbs -ato

Microsoft (R) Windows Script Host Version 5.8
Copyright (C) Microsoft Corporation. All rights reserved.

Activating Windows Server(R), ServerStandard edition (68531fb9-5511-4989-97be-d1
1a0f55633f) …
Product activated successfully.

Keywords: activating windows, firewall, KMS, TMG

SCOM 2007 R2 CU 4

On tegelikult juba jupp aega olemas (2011 jaanuari lõpust), kuid teatud probleemide tõttu pole ma sellest siiani pikemalt kirjutanud.

Kuigi CU parandab mitu olulist viga (Agentide seiskumine, Diagram View jõudlus, Alert view poolik töötamine) on seal suuremat sorti häda agendi käitumisel. Nimelt Windows 2008 ja 2008 R2 puhul võib tekkida olukord, kus agendi uuendamisel tehakse restarte ka mitte Scom teenustele. Selle tagajärjel võib mõni teenus ootamatult maha käia  ja see pole kindlasti oodatud käitumine.

Teadmusbaasi artiklis 2449679 on sellest ja teistest probleemidest räägitud.

CU 4 on tegelikult vajalik siis, kui see ravib mõne sinu keskkonnas eksisteeriva probleemi või kui soovid SCOM’I andmebaasi kolida SQL 2008 R2 peale (see on nüüd toetatud). Sel juhul peaksid keelama agentide uuendamise või sättima agentide uuenduse  serverite hooldusaegadele.

Kui vähegi võimalik – oota hoopis CU 5  saabumist, kuid hetkel pole selle ilmumisaega avalikustatud.

Väga põhjalikult kirjutab sellest probleemist ja üldse kogu uuenduse käigust  Kevin Holman oma blogis.

 

 

Keywords: SCOM 2007 R2 CU4 , Update

RDP Console ja Admin

Remote Desktop (aka Terminal Services)  on Microsofti maailmas juba suhteliselt vana teenus – esimesena ilmus ta Windows 2000 Server koosseisus (tollal küll tiba teise nimega). Tööjaamadesse tuli Windows XP saabudes. Edaspidi on teda kõpitsetud siit ja sealt poolt, nii et tänaseks hetkeks on tegemist päris võimsa ja kasutatava omadusega.

Allpool räägin valdavalt Terminal Service for Administration alamliigist. Ehk siis teenus, mis on mõeldud Windows Serveris peamiselt administreerimistööde tegemiseks. Kliendilitsentsi (TS/RDS CAL)siinjuures vaja ei lähe, kuid sessioonide arv on piiratud 2’ga. Edasi läheb keeruliseks.

Windows 2000 ‘des – oli võimalik 2 “virtuaalset” (edaspidi lihtsalt RDP) sessiooni. Need mõlemad EI olnud samad, mis füüsiliselt serveri kuvari ja klaviatuuri taha istudes sisselogides avanes. See omakorda tekitas probleeme paljude rakendustega, mis ei osanud virtuaalsete sessioonidega hakkama saada ja väljastasid tulemused ja ootasid sisendit nn konsoolilt. Tööjaamas (Windows 200 Professional) polnud see üldse võimalik.

Windows 2003 parandas selle vea. RDP rakendust (või analooge) spetsiaalse võtmega  /console käivitades ühenduti konsooli sessioonile. See sessioon oli alati ID’ga 0

image

Seega sai Windows 2003/2003 R2 serveris korraga töötada maksimaalselt 3 kasutajat. Terminal Services Configurator abil  oli võimalik muuta maksimum kasutajad 0..2+1 konsooli oma.  Vaikimisi häälestuses pääsesid RDP’le ligi ainult lokaalsesse Administartors gruppi kuluvad kontod. Lokaalse Remote Desktop Users grupi kaudu sai ligi lasta ka mitte administraatoreid, KUID konsooli sessioon jäi kasutatavaks ainult administrator kasutajatele. Mitteadministrators said /console võtmega väga üheselt mõistetava veateate

image Väga mugav.

Windows XP –  lubas ainult nn konsoolisessiooni.

Olukord muutus dramaatiliselt Windows Vista/Windows Server 2008/R2 arenduse edenedes. Esmalt kogesid seda Vista SP1/XP SP3 installijad, kui uuendati RDP klienti. /console ei töötanud ootamatult ja see tuli asendada /admin võtmega. Hea küll, hulk skripte tuli ümber muuta ja ports 3’nda partei tööriistu lakkas korrektselt töötamast, kuid 2003 perekonna funktsionaalsus säilus.

Windows 2008 serveris  on muudatused suuremad.

  1. Remote Desktop Service häälestamine käib uue väljanägemise saanud konsooli kaudu, kus on ports uusi võimalusi.
  2. Konsoolisessiooni, kui sellist pole enam üldse. Sa võid võtme /admin kaasa anda, kuid konsoolisessiooni (sessiooni 0) ikkagi enam ei saa.
  3. Võti /admin on vajalik ainult juhul, kui soovid administreerida Windows 2008 Serverit, millel on installeeritud Remote Desktops Services roll. Sel juhul keelatakse mõningad ümbersuunamised, töölaua teema lülitatakse Classic peale ja TS CAL’i ei loeta.
  4. Vaikimisi on kehtiv 2 aktiivse kasutaja piirang. Disconnected kasutajaid võib teoreetiliselt olla lõpmatult. Kui serverisse tahab logida uus kasutaja ja eelnevalt on aktiivsed 2 kasutajat palutakse valida, milline kasutaja välja logida. Administratori õigustega uuel logijal on võimalus eelmisi jõuga disconnectida, lihtsalt kasutaja puhul force puudub, kuid valitud aktiivsele kasutajale kuvatakse oma sessiooni disconnectimise teade ja kui ta sellele ei reageerita, siis 30 sekundi pärast tehakse disconnect ikkagi. Isegi siis kui uus login on user ja disconnect tehakse administraatorile…

image

4. RDP sessiooni saavad avada jätkuvalt vaikimisi administraatorid või siis Remote Desktop Users gruppi kuuluvad kontod.

Seda olukorda iseloomustab kenasti ka Task Manager, kus ID 0 sessioone enam tekitada ei õnnestu.

image

Täpsemalt saab aimu qwinsta käsuga, kus ID 0 sessioon on reserveeritud süsteemile. >märgiga on tähistatud jooksev kasutaja ja RDP-TCP#0 on lihtsalt identifikaator.

image

 

Kogu pika jutu kokkuvõte on see, et KUI Windows 2003’s on võimalik tekitada lihtsalt ja välditavalt olukord, kus serverisse saab RDP’ga logida korraga ainult 1 mitte administraatorist kasutaja ja administrator saab alati konsooli kaudu ligi. Peamiselt vältimaks olukorda, kus parem käsi ei tea mida teeb vasak või mingitel  tegevuste salvestamise kaalutlustel, siis Windows 2008’s pole see nii lihtne, kuna alati saab mitteaktiivse kasutaja disconnectida.

Ma ei ole leidnud veel võimalust, kuidas blokeerida tavakasutaja võime seesolevaid kasutajaid disconnectida. Logoff ta neile teha ei saa.

Lisalugemist – “Impact of Session 0 Isolation on Services and Drivers in Windows Vista” (http://go.microsoft.com/fwlink/?LinkId=106201).