Exchange verzió (SP, RolUP, build number) meghatározása

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.

GPP több-opciós ablakok

Asteriksz's Blog

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).

View original post

Veeam licensz váltás ingyenes community edition-re (Revert from licensed Veeam to free Community Edition)

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)

 

Revert from licensed Veeam to free Community Edition

Gyors elérés (Quick Access) Exploer (Intéző) -ben nem működik meghatározhatatlan hiba

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

Active Directory Certificate Services could not publish a Delta CRL for key 1 to the following location hiba

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

CertificationAuthority_error_66

3, Menjünk a CN=Configuration/CN=Services/CN=Public Key Services konténerhez.

CertificationAuthority_error_66_2

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.

Remote Desktop Servers -The servers must be added to the server pool

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.

Theerversmustbeaddedtotheserverpool

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.

 

FSMO szerepkörök mozgatása

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

 

Outlook 2013 nem csatlakozik O365-re Exchange-ről migrálás után

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

Certificate Windows Event IDs 6, 13, 82 és RPC server is unavailable 0x800706BA hiba

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.

Fel ↑

%d blogger ezt szereti: