Az Exchange (2010, 2013, 2016, 2019) szerver verzió meghatározása legegyszerűbben úgy lehetséges ha ,egy ExhangeAdmin console-ban kiadjuk a lenti parancsot:
gcm exsetup | %{$_.fileversioninfo}
Majd innen kikeressük a file version info alapján a verziót és már tudjuk is melyik frissítés van rá telepítve.
Azt tapasztalom, hogy még mindig nem mindenki jártas a GPP azon esetében, amikor pl. a Control Panel szekcióban a regionális beállításokat kell kezelni (ahol több mindent tudunk szabályozni). Az nem elég, ha beállítjuk a kívánt formátumot/értéket, hanem “aktiválni” is kell (erre utal az alapértelmezett piros aláhúzás is).
Ehhez a következő billentyűkombinációkat kell ismerjük:
F5: az aktív fülön mindent aktivál
F6: az aktuálisan kijelölt sort aktiválja
F7: az aktuálisan kijelölt sort deaktiválja
F8: az aktív fülön mindent deaktivál
Abban az esetben, ha elég egy módosítást kiszórnunk, úgy a többi maradhat piros színnel aláhúzva (ez a “Not configured” állapotnak felel meg).
Egy kisebb környezetben jött elő az igény, hogy licenszelt Veeam Backup verzióról a support lejárta után szeretnének átállni Veeam Community Edition-re, lehetőleg újra telepítés nélkül. Ezt úgy lehet megtenni, hogy a lenti registry kulcsot töröljük:
HLKM\SOFTWARE\Veeam\Veeam Backup and Replication\License\Lic1 (REG_BINARY)
Egy terminál szerver felhasználónál jelentkezett a probléma, hogy az Explorer lefagyott ha az intézőben a Quick Access (Gyors elérés) -re kattintott és ha könyvtárat vagy filet szeretet volna hozzáadni, akkor nem meghatározható (Unspecified) hibaüzenet volt a válasz :-). A megoldás Windows 10 és 2019, 2016 RDS esetén is, hogy a lenti két útvonalról töröljük a könyvtárakat és file-okat.
%AppData%\Microsoft\Windows\Recent\AutomaticDestinations%AppData%\Microsoft\Windows\Recent\CustomDestinations
Magára a CA szerepkör migrálására számtalan leírás található, ez példáúl jól követhető:link
Ca server 2008R2 ről történő migrálása után, az event-logba az alábbi hiba üzenet került minden egyes CA server szolgáltaás indulásakor:
“Active Directory Certificate Services could not publish a Delta CRL for key 1 to the following location ldap:///CN= Operation aborted 0x80004004 (-2147467260 E_ABORT).”
Source:CertificationAuthority id:66
A hiba megoldása, hogy az új szerver nem rendelkezik megfelelő jogosultsággal a Ad-ban. A jogosultság megadása a következő képen történik:
1,Indítsunk a domain controleren egy ADSI Edit-et.
2,Csatlakozunk a konfiguráció paricióhoz
3, Menjünk a CN=Configuration/CN=Services/CN=Public Key Services konténerhez.
4,Az AIA -n a Security fülön (jobb klikk/tulajdonságok) adjuk hozzá a CA szerver computert és adjunk neki módosítás jogot.
Egy újra indítást követően a szerver manager-ben az RDS fam-ot és conection brokert nem lehetet adminisztrálni és az alábbi hiba fogadott:
The following servers in this deployment are not part of the server pool:
RDSlicense.domain.com. The servers must be added to the server pool.
Az első meglepetés után csak annyi a teendőnk, hogy a szerver managerhez újra hozzáadjuk az összes RDS host-ot és a connection broker szervereket és újra indítjuk a szerver manager-t.
Egy 2008R2 -ről 2019 re migráció során kellet egy kis összefoglaló, hogy a FSMO szerepköröket, hogy lehetséges mozgatni. A szerepkörök a következők:
Erdő szintű szerepkörök:
Schema Master
Domain naming master
Doamin szintű szerepkörök:
PDC
RID pool manager
Infrastructure Master
A szerepkörök mozgatásához szükséges jogosultságok:
| Schema master | Schema Admins |
| Domain Naming | Enterprise Admins |
| RID | Domain Admins |
| PDC Emulator | |
| Infrastructure |
Melyik domain controller melyik szerepkört hordozza?
Admin módban futatott parancs sorba futtassuk:
netdom query fsmo
Admin módban futatott powershel-ben:
Get-ADDomain | Select-Object InfrastructureMaster, RIDMaster, PDCEmulator Get-ADForest | Select-Object DomainNamingMaster, SchemaMaster
Szerepkörök mozgatása:
Gui-t használva az alábbi mmc-modulokra van szükség:
Active Directory Schema snap-in (először szükséges lehet futtani a
regsvr32 schmmgmt.dll parancsot)
Active Directory Domains and Trusts snap-in
Active Directory Users and Computers snap-in
Ntdsutil használatával:
Admin módba indítsunk egy parancs sort majd sorrendben a következő parancsok:
ntdsutil roles connections (itt ahoz a domain controllerhez csatlakozunk ahova mozgatni szeretnénk) quit ransfer schema master type transfer rid master transfer naming master transfer pdc and transfer infrastructure master
majd a quit -el lépjünk ki az ntdsutil-böl.
Powershell:
Import-Module ActiveDirectory Move-ADDirectoryServerOperationMasterRole -Identity “S2” –OperationMasterRole DomainNamingMaster,PDCEmulator,RIDMaster,SchemaMaster,InfrastructureMaster
S2 az a szerver neve ahova mozgatni szeretnénk.
A szerepköröket rövidíthetjük számmal is:
Move-ADDirectoryServerOperationMasterRole -Identity “S2” –OperationMasterRole 0,1,2,3,4
PDCEmulator:0
RIDMaster:1
InfrastructureMaster:2
SchemaMaster:3
DomainNamingMaster:4
Egy Exchange-ről O365 migrálásnál és komplett új ad építésekor és új felhasználói profile létrehozása után fordult elő, hogy miután átírtuk az autodiscovery dns bejegyzést, hogy az o365-re mutasson, az Outlook 2016 kliensek gond nélkül csatlakoztak az Outlook 2013-ak nem. Kiderült, hogy az ügyfél nem csak dns autodiscovery-t hanem a web oldalán is elhelyezett autodiscovery-t az exchange szervere (Kliensek nem voltak régen domain-tagok) és az Outlook 2013 azt vette erősebnek a dns bejegyzésnél.
Ilyen esetben megoldás, hogy vagy registry bejegyzéssel vagy GPO használatával ráveszük az Outlook-ot, hogy ne használja csak a dns bejegyzést. (Hosszú távon mindenkép le kell vetetni a weboldalról az autodiscovery-t.).
GPO és registry beállítások: link
2008R2 és 2012R2 doman controller-ek migrálásakor futottam bele, hogy a az új 2019-es domain controller-ek esemény naplójában rendszeresen a Certificate Windows Event IDs 6, 13, 82 hiba üzenet került be, és mint később kiderűlt domain controller certificatet- se kaptak automatikusan és mikor kézzel próbáltam igényelni domain controller tanúsítványt az mmc konzolban RPC server is unavailable 0x800706BA hibát kaptam.
Mint kiderült két dolog miatt vérzett el a dolog. Az első, hogy valamikor (még SBS2007-ről migráltak sima windows szervere és exchange 2010-re), nem lett rendesen kivezetve a active directory certificate server és bent maradtak rá mutató bejegyzések az active directory-ban. Ezeket a bejegyzéseket az alábbi link alapján tudjuk kitakarítani:
Cleaning up after the removal of a server that was hosting the Active Directory Certificate Services (AD CS) role
Ki takarítás után is még jöttek a fenti hiba üzenetek. A megoldás végűl az volt, hogy a CERTSVC_DCOM_ACCESS ad csopotból hiányzott a tartomány vezérlők csoport.
Erről itt egy leírás: link
Üzemelteti a WordPress.com. , Anders Noren fejlesztésében.
