Kasulik asi – kui windows annab vea “path to long” failide kustutamisel.

Pange see enda admini “Šveitsi noa komplekti”.

Päästab välja kui igasugused muud meetodid (subst, robocopy, device named) ei tööta.

http://deepremove.codeplex.com/

Advertisements

Ja veel mõned viited veakoodidele

Kergema hilisema ülesleidmise huvides olgu siin veel mõned vanad kohad kus veakoode kirjas:

NT Status Codes – https://msdn.microsoft.com/en-us/library/cc231200.aspx

Üleüldse on https://msdn.microsoft.com/en-us/library/cc231196.aspx päris asjalik.

Samuti võib kiigata Dev Centris olevasse https://msdn.microsoft.com/en-us/library/windows/desktop/ms681381(v=vs.85).aspx

, kuigi see on mõne koha pealt hõredavõitu.

Kuidas kiirelt tõlgendada veakoode.

Vana, aga meenutuseks.

Mõnikord esitatakse veakoodid numbriliselt ja suhteliselt loetamatult. Ok, kogenud admin mäletab peotäit koode peast ja une pealt. Aga mõnikord läheb ikka väikest värskendust vaja. Tehtav lokaalis võrguühenduseta (ei pea guugeldama)

Error 2147943785 – see teisenda Hexi 0x80070569 ( Windowsi kalkulaatoriga või kuidas mugavam on)

0x8007 = win_32

0x 0569 teisenda dec = 1385

Ja nüüd cmd/PS promptist

net helpmsg 1385

mis annab tulemuseks

Logon failure: the user has not been granted the requested logon type at this computer.

Windows Update ja server CORE

Windows Server Core on paljuski kasulik valik – väiksem installatsiooni jälg, vähem komponente, vähem auke, vähem paikasid, vähem muret.

Aga – kui midagi ei toimi just päris nii nagu tahaks, siis on natuke keerukam. Windows GUI peal on võimalik rohkem vähem mugavalt kasutada Control Paneli appi Windows Updates. Corel seda pole.

Alljärgnevalt vaatame, kuidas opereerida Updatedega Core keskkonnas.

 

A – Mul on täiesti iseseisev CORE

( pole domeeni, WSUS’i ega midagi).

Põhimõtteliselt on siin 2 varianti – täiesti automaatne paikamine või korra (või kaks) kuus käsitsi.

Automaatsekscscript scregedit.wsf /AU 4

Sellega häälestatakse server ise kõiki patche MIcrosofti serverites alla tõmbama ja installima ja buutima.

Tagasi manuaalseks cscript scregedit.wsf /AU 1

Natuke paindlikum ( kuid kindlasti ajamahukam) on sconfig abil ise patche scannida, alla laadida ja installida.

Loomulikult ei keela keegi ka mingit iseseisvat scripti ehitada mis patche kuskilt kohalikust failisüsteemist installeerib.

B – Mul on domeeni kuuluv CORE

Võid kasutada kõike eelnevat, kuid mugavam on Group Policyga paika panna millisel serveril kuidas ja millal. Vaikimisi on Update source serveriks jätkuvalt MS serverid. Koheseks patchimiseks ikka ja jälle sconfig.

C – Mul on domeen ja oma WSUS/SCCM

Esimesel juhul tuleks ise GP’ga määrata lisaks käitumisele ka WSUS serveri nimi. SCCM’i korral teeb kogu musta maagia SCCM’i klient ja GPOga midagi üle käia on ebavajalik võib-olla ilmselt isegi ebasoovitav.

Kui Sinu WSUS/SCCM töötab perfektselt siis peaks elu olema “lill”. Mõnikord aga juhtub, et seal või kuskil mujal on väiksed bugid. Siis on vaja uudrida, mis ja kus katki on.

Kui sconfig väidab, et siin ei ole ühtegi pachi installida, kuid me teame ( või keegi teeb pentesti ja ütleb meile, et ikka  on küll) võime eeldada, et midagi on katki meie WSUS/SCCM serveri või ühendusega sinna.

Kuidas teha patch scanni MS serverite vastu (eeldusel, et võrgu tasemel on sinna juurdepääs olemas) ?

  1. Regedit (jah, see on core peal olemas!), otsi üles [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU] UseWUServer ja muuda väärtus 0’ks. Sulge regedit.

  2. taaskäivita Windows Update service ( net stop “windows update” ja seejärel  net start “windows update”)

  3. sconfig ja kontrolli updatesid

  4. pärast tagasimuutmiseks muud aregistry väärtus taas 1’ks ja teenusele restart.

SCCM poolelt on CORE’sse installeritud nii SCCM Control Panel aplett (c:\windows\ccm\smscfgrc.cpl) kui ka Software Center (C:\windows\ccm\scclient.exe). Ka nendega saad algatada kliendi poolsed tegevusi.

Keywords: Windows update, Core, Online, check

Lingering, lingering ….

Ilusad sõnad, tahaks peaaegu laulda, kui ei teaks nende sõnade halvamaigulist tähendus Active Directory kontekstis.

Lingering Objects – ehk siis jäänuk objektid (vabandust, pole õiget tõlget) on AD objektid mis on peamiselt tekkinud halvasti töötava replikatsiooni tagajärjel. Koos virtualiseerimise levikuga avanes veel üks võimalus – nn tagasikerimine, kus DC P2V muutmisel tehti vigu või DC taastati VM snapshotist  protseduure jälgimata.

Suurem tõenäosus jäänukobjekte kohata on suurtes AD implementatsioonides, mis hõlmavad paljusid DC sid ja paljusid ( sageli ebakindla Interneti VPN’iga) ühendatud andmekeskusi. Ja kui neid haldavad veel erinevad tiimid (erineva kompetentsi tasemega) siis …

Jäänukobjektide esimene avaldus on see, et AD ei taha enam replikeeruda – sellest saab mööda, kui lubada “non-strict” replikeerumisviis. KUID, see ei kõrvalda algpõhjust. Jäänukobjektide kõrvaldamine eeldas omajagu käsitööd ldp ja repadmin’ tööriistadega. See oli tüütu ja nõudis suurt täpsust.

Hiljuti sa MS AD team “valmis” (noh, betasse) SUUREPÄRASE tööriista – Lingering Object Liquidator (LOL) ’i. Seda ei jagata veel päris avalikult ja selle kasutamine nõuab veel siiski teadmisi ( ja õigusi ) aga siiski on tegu suure sammuga edasi.

Tervet kasutusjuttu pole mõtete ümber rääkida. Härrad ja Prouad – see on tõeline kullafond.

Microsoft Message Analyzer – WoW!

image

  Nädala alguses ühte kentsakat võrguprobleemi lahendadedes komistasin juhuslikult ühe järjekordse põneva ja paljulubava tööriista otsa. Palun- tutvuge -  hardcore administraatori uus mängukaaslane – Microsoft Message Analyzer.

Alla laadida saab SIIT ja tootegrupi blogi on SIIN.

 

Ehk siis lühidalt on tegemist Network Monitori, WireSharki edasiarendusega. Ehk siis võrguliikluse (mitte ainult!)  koguja ja anlüsaatoriga. Lihtsaid võrguliikluse kogujaid on internetis saadaval ilmselt kümmneid, kuid kui sinu igapäevatöö pole just hommikust õhtuni võrgutasemel mudistamine, siis võib kogutud info reaalne sisu natuke hägusaks jääda. Network Monitori puhul aitasid välja laienduspakkidena jagatud “Eksperdid” , Message Analyseril on seda ideoloogiat edasi arendatud ja neid kutsutakse OPN Parseriteks.

Süvenedes võimalustesse on MMA ikka täiesti järgmise põlvkonna toode.

Lühidalt on MMA  järgmiste võimalustega:

  • võrgupakettide ja sündmuste (Windows event) reaalajas salvestamine
  • pakettide ja sõnumite töötlemine ja valideerimine
  • ETW sündmuste kogumine ja töötlemine
  • kirjeldavad graafikud (sügavuti mineku võimalusega)
  • sõnumite automaatne grupeerimine vestlusteks
  • erinevate logitüüpide toetamine
  • pakettide sisu (payload) renderdamine
  • stenaariumite tugi (komplekteerid just Sulle vajaminevad allikad, logid, vaated jne)
  • hullumeelselt parandatud Filtrite loogika ( + InteliSense UI)
  • Remote capture

 

Samas on ka mõned puudused:

  • ei tööta Vista põlvkonnast vanemate OS’ide peal.
  • puudub tugi võrgukaardi promiscuous modele (Kui seda on vaja siis võib logida NM abil ja analüüsida MA abil)

Jauramine SCCM Compliance Settings’itega

Compliance settings (vana nimetusega Desired Configuration Management ehk DCM selelst ka palju viiteid “DC”le ) on suurepärane vahend auditeerimaks, et igasugused süsteemi häälestused, installatsioonid ja parameetrid on täpselt nii, nagu IT turva-, haldus- või auditi meeskond soovib. Mõningal määral saab seda teha ka Group Policy objektidega, kuid sel juhul jääb puudu võimas raportikeskkond. SCCM reportserverist võid kasvõi iga päev vastvad raportid automaatselt teele panna.

Ehk jah, CS on tööriist, mis on mõttekas endale selgeks teha ja kasutada.

Hiljuti komistasin naljaka kõrvalefekti otsa – mõningad Configuration Item’id annavad teatud juhtudel vigu. Tegemist ei olnud mingi keerulise päringu või skriptiga – lihtsalt võeti registryst teatud võtmeid ja kontrolliti nende olemasolu või vastavust etteantud väärtustele. Hmmm. uurimise käigus selgus, et Complianciga pole valesti midagi, ehk – reaallselt on vastvad registry võtmed täiesti olemas ja päritavad. REG utiliidiga käsurealt käitus päring täpselt nii nagu oodatud, kuid – SCCM klient andis visalt tulemuseks “Non-Compliant”.

Egas midagi – SCCM klient logib ohjeldamatult ( no õnneks siiski mitte ketast täitvalt) ja täpselt. Compliance Setting’u  kontrollimise sammud salvestuvad järgmistes logifaildes:

DcmWmiProvider.log , DCMReporting.log, StateMessageProvider.Log. Tegelikult on CS’iga seotud veel mõned logifailid kuid need ei paku hetkel huvi.

DCMReportingust loeme välja et Registry väärtuste lugemisel kasutatakse WMI instrumentaariumi. OK. WMI on selline asi, mis tikub omama 1001 bugi ja pidevalt katki olema. Samas eventLogis starditakse WMI ja käivitatakse päring probleemideta.

Ehk siis – proovime uuemat WMI – http://www.microsoft.com/en-us/download/details.aspx?id=34595

Selle peale teeb SCCM klient repairi ja SC Baseline muutub hetkeks ( tegelikult siis seniks kuniks pole toimunud uus kontroll)  kompatiibliks. Hmm..

Ehk siis võiks arvata et kliendis on mingi bugi – vahepeal on valja tulnud ka SCCM 2012 R2 Sp1 CU 4 -  mis küll serveritel peal, kuid kliendid pole veel kõikjal uuendatud.

Pane uuema kliendi paiga ka peale ja voilaa – Compliance jääb samuti rahule.

 

CS CI’d  isenesest laetakse  XML failidena C:\Windows\CCM\CIDownloader\DigestStore kausta.  Nende kohalejõudmise kiirendamiseks tee “Machine Policy Rretrieval and evalution” tegevusel käivitus. Sealt saab vaadata kas masinas ikka on sama sisuga CI kui serveris tehtud.

 

 

Keywords: DCM , non-compliant, registry, value.