Având un Windows Server 2016 (găzduit la Amazon AWS EC2) care rulează cu succes de ani de zile.
De câteva luni, mă confruntă cu sarcinile programate (de exemplu, o sarcină care este configurată să ruleze zilnic) nu sunt executate. Niciun mesaj de eroare în istoricul sarcinilor. Nicio intrare în jurnalul de evenimente. Nimic.
Sarcinile pur și simplu nu rulează, iar în coloana „Next Run Time” este o dată în viitor, de ex. Mâine. Când se uită din nou mâine, aceeași imagine: nu a rulat nicio sarcină, „Next Run Time” indică din nou spre viitor.
Iată un alt exemplu despre cum arată șansele în timpul sistemului meu:
Mai sus, o captură de ecran a Windows Update arată că o actualizare a SQL Server pe care am instalat-o la 5-a februarie 2022 este de fapt afișat în mod eronat ca fiind instalat la 5 Martie 2022. O lună în viitor.
Tocmai am apelat asta în linia de comandă:
C:\>w32tm /query/status
Care a imprimat acest rezultat:
Indicator de salt: 0 (fără avertizare)
Strat: 4 (referință secundară - sincronizare prin (S)NTP)
Precizie: -6 (15,625 ms per bifă)
Întârziere la rădăcină: 0,0096024s
Dispersia rădăcină: 0,0493815s
ReferenceId: 0x28779426 (IP sursă: 40.119.148.38)
Ultima sincronizare cu succes: 08.02.2022 08:41:13
Sursa: time.windows.com,0x8
Interval sondaj: 10 (1024s)
Nimic suspect nu se uită la mine.
De asemenea, am verificat dacă există viruși fără niciun rezultat pozitiv. Am condus și eu Instrument „MRT”. fara niciun aspect pozitiv.
Ultima dată când s-a întâmplat asta, poate acum o lună, mi-am repornit sistemul și cred că acest lucru a rezolvat (temporar) problema. Doar să apară acum din nou.
Având mai multe alte servere EC2 AWS Windows 2016 și zeci de alte servere Windows de administrat ani de zile, am nu a dat peste un comportament atât de ciudat.
Intrebarea mea
Are cineva idee ce s-ar putea întâmpla pe acest server și cum să rezolve acest lucru?
Actualizare 1
Se pare că acest lucru a avut loc pentru prima dată după o comutare automată a orei de vară (serverul și fusul orar sunt în Germania).
Unele dintre sarcini aveau acest mesaj ca „Rezultatul ultimului rulare”:
Operatorul sau administratorul a refuzat cererea. (0x800710E0)
In germana:
Die Anforderung wurde vom Operator oder Administrator zurückgewiesen. (0x800710E0)
Toate sugestiile pe care le-am găsit despre această eroare (cum ar fi, de ex. Aceasta) trebuia să editeze și să stocheze din nou sarcinile. Voi încerca asta acum.
Actualizare 2
Activitățile programate nu au rulat din nou și am găsit mai multe intrări precum următoarele în jurnalul de evenimente:
Ora de sistem s-a schimbat la â2022â-â03â-â20T01:25:40.348000000Z de la â2022â-â02â-â416-â:47:40. :49.130142400Z.
Motivul modificării: O aplicație sau o componentă de sistem a modificat ora.
Deci a fost schimbat la o lună în viitor.
Și mai târziu, a fost schimbată din nou la data corectă:
Ora sistemului s-a schimbat în â2022â-â02â-â16T12:04:30.541000000Z din â2022â-â03â-â37-â :24.558311600Z.
Motivul modificării: O aplicație sau o componentă de sistem a modificat ora.
Deci, aceasta a schimbat data cu o lună în viitor și înapoi. Se pare că acest lucru este suficient pentru a-mi încurca sarcinile suficient pentru a nu mai alerga niciodată.
Inca nu stiu motivul.
O sugestie pe care am găsit-o cu privire la aceste intrări din jurnalul de evenimente a fost aceea reînregistrați serviciul de timp:
net stop w32time
w32tm /unregister
w32tm /register
net start w32time
Deoarece serverul rulează pe EC2 la Amazon, AWS, nu voi încerca această comandă:
w32tm /config /manualpeerlist:169.254.169.123 /syncfromflags:manual /update
Și, de asemenea, această comandă:
reg add "HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\TimeZoneInformation" /v RealTimeIsUniversal /d 1 /t REG_DWORD /f
Apoi, pentru ca sarcinile programate să ruleze din nou, le voi deschide pe fiecare și le voi salva din nou.
Actualizare 3
Acum am experimentat din nou schimbări de timp, iată cum arată intrările din jurnalul de audit.
În primul rând, schimbarea a avut loc la 133 de zile în viitor:
Intrarea selectată la „17.03.22 06:47:44” are următoarele detalii:
A fost creat un nou proces.
Subiectul creatorului:
ID de securitate: SYSTEM
Numele contului: EC2AMAZ-K5BI954$
Domeniul contului: WORKGROUP
ID de conectare: 0x3E7
Subiect țintă:
ID de securitate: NULL SID
Nume de cont: -
Domeniul contului: -
ID de conectare: 0x0
Informații despre proces:
ID de proces nou: 0x3478
Nou nume de proces: C:\Windows\System32\conhost.exe
Tip de cotă a simbolului: %%1936
Etichetă obligatorie: Etichetă obligatorie\Nivel obligatoriu de sistem
ID proces de creator: 0x44bc
Numele procesului creator: C:\Windows\System32\wbem\WMIC.exe
Linia de comandă a procesului: ??\C:\Windows\system32\conhost.exe 0xffffffff -ForceV1
Token Elevation Type indică tipul de jeton care a fost alocat noului proces în conformitate cu politica de control al contului de utilizator.
Tipul 1 este un token complet fără privilegii eliminate sau grupuri dezactivate. Un simbol complet este utilizat numai dacă Controlul contului utilizatorului este dezactivat sau dacă utilizatorul este un cont de administrator încorporat sau un cont de serviciu.
Tipul 2 este un token ridicat, fără privilegii eliminate sau grupuri dezactivate. Un token ridicat este utilizat atunci când Controlul contului utilizatorului este activat și utilizatorul alege să pornească programul utilizând Run ca administrator. Un token ridicat este, de asemenea, utilizat atunci când o aplicație este configurată să necesite întotdeauna privilegii de administrare sau să solicite întotdeauna privilegii maxime, iar utilizatorul este membru al grupului Administratori.
Tipul 3 este un simbol limitat cu privilegii administrative eliminate și grupuri administrative dezactivate. Indicatorul limitat este utilizat atunci când Controlul contului utilizatorului este activat, aplicația nu necesită privilegii de administrare și utilizatorul nu alege să pornească programul folosind Executare ca administrator.
Și prima intrare la noua dată (greșită) în viitor „28.07.22 13:52:50” a fost:
A fost creat un nou proces.
Subiectul creatorului:
ID de securitate: SYSTEM
Numele contului: EC2AMAZ-K5BI954$
Domeniul contului: WORKGROUP
ID de conectare: 0x3E7
Subiect țintă:
ID de securitate: NULL SID
Nume de cont: -
Domeniul contului: -
ID de conectare: 0x0
Informații despre proces:
ID de proces nou: 0x1f64
Nou nume de proces: C:\Program Files (x86)\Google\Update\GoogleUpdate.exe
Tip de cotă a simbolului: %%1936
Etichetă obligatorie: Etichetă obligatorie\Nivel obligatoriu de sistem
ID proces creator: 0x4a8
Numele procesului de creator: C:\Windows\System32\svchost.exe
Linia de comandă a procesului: „C:\Program Files (x86)\Google\Update\GoogleUpdate.exe” /ua /installsource scheduler
Am căutat pe google pentru „??\C:\Windows\system32\conhost.exe 0xffffffff -ForceV1” și a găsit mai multe articole care susțin că acest lucru ar putea fii rău intenționat:
Ora sistemului a fost ulterior setată automat înapoi de către sistem:
De fapt, mai întâi a fost schimbat prea mult înapoi la 16.03.2022 și imediat după aceea la ora corectă 17.03.2022 din nou.
Detaliile intrării arată astfel:
Ora sistemului a fost schimbată.
Subiect:
ID de securitate: SERVICIUL LOCAL
Numele contului: SERVICIUL LOCAL
Domeniul contului: NT AUTHORITY
ID de conectare: 0x3E5
Informații despre proces:
ID proces: 0x4a0
Nume: C:\Windows\System32\svchost.exe
Ora anterioară: â2022â-â07â-â28T11:59:14.787568600Z
Ora nouă: â2022â-â03â-â16T15:02:28.443000000Z
Acest eveniment este generat atunci când ora sistemului este schimbată. Este normal ca Windows Time Service, care rulează cu privilegii de sistem, să modifice în mod regulat ora sistemului. Alte modificări ale orei sistemului pot indica încercări de modificare a computerului.
Așa că acum, chiar și după ce am activat auditul, sunt încă complet confuz cu privire la ceea ce se întâmplă pe sistemul meu.
Actualizare 4
În cele din urmă, am renunțat și am configurat o altă mașină AWS EC2, de data aceasta un Windows Server 2022.
Am migrat totul manual de pe vechiul server pe noul server (fișiere, baze de date, site-uri web IIS etc.).
Funcționează de la cca. Acum 2 saptamani fara probleme.
Deși aceasta nu este o soluție tehnică, este cel puțin una funcțională.
