Content from the Shard mailbox error postafiok O365-be mozgatásakor

Egy Exchange 2010 O365-be költöztetésekor jött elő postafiok felhőbe költöztetésekor az alábbi hiba üzenet:
“Content from the Shard mailbox (Mailbox Guid: 2e776b72-b014-4c12-8624-166a4e839680, Database: ad8e7551-5c10-4b89-9b04-894e8dccdd04) will be merged into the target mailbox.”

A migráláshoz  Modern Hybrid Agent-et használtuk, a felhasználókat ADConnect-el szinkronizáltuk.

Megoldás:
Kapcsolódjunk powershell-el az Exchange online-hoz, és futtassuk le a :

Get-MailboxLocation “emailaddress”

Ha a MailboxLocationType : ComponentShared  látható akkor nyomon vagyunk.

A megoldás, hogy a felhasználót teljesen kitöröljük az O365-ből majd újra szinkronizáljuk.

A törlést csak powershell használatával lehetséges.

Csatlakozzunk az AzueAd-hoz :

Connect-msolservice

Csatlakozás után töröljük a felhasználót:

remove-msoluser -userprincipalname <username@domain.com>
remove-msoluser -userprincipalname <username@domain.com> - removeFromRecycleBin

Ezek után várjuk meg, hogy újra felszinkronizálódik a felhasználó, vagy kényszerítsük ki az AdConnect azonnal szinkronizáljon.

Start-ADSyncSyncCycle -PolicyType Delta

 

 

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.

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

SearchOCR.ADMX error after installing Win10-1903 ADMX templates

Group policy Central Store 1903  template update után hiba üzenet:
Resource ‘$(string.Win7Only)’ referenced in attribute displayName could not be found. File \\SysVol\…\Policies\PolicyDefinitions\SearchOCR.admx, line 12, column 69

Ez egy régi ismerős hisz előjött már 1803-nál is a megoldás is ugyanaz. Használjuk a 1809-es verziót a SearchOcr.admx-ből vagy szerkesztjük a filet: link

 

 

 

Windows update: We’re having trouble restarting to finish the install. Try again in a little while.

Minap egy Windows Server 2019 Domain kontroller elmaradt frissítéseit, kellet rendbe raknom és miért is ment volna simán? 🙂 A frissítések telepítése után restatart-ra kattintva az alábbi hiba üzenet jött:

We’re having trouble restarting to finish the install. Try again in a little while. If you keep seeing this, try searching the web or contacting support for help. This error code might help: (0x8007000)

Restart majd újra próbálkozás se hozott eredményt. Majd kutató munka után a megoldás az volt, hogy  egy bug miatt a kapott user-emnek nincs megfelelő joga.
Ehhez a local gpo-ban adjuk hozzá a felhasználót a lenti Policy-hez.

Vagy Pedig az UAC beállítást módosítsuk a telepítés idejére (Disable):

 

Windows_update_error_(0x80070005)

Connecting to guest OS via VIX Error Veeam Test Credential

Ha VmWare szerveren beállítjuk a vendég oprendszer file vagy  application indexelést és a hozzá tartozó felhasználót akkor érdekes dolgot tapasztalunk a teszt gomb megnyomásakor.
A teszteléskor a Connecting to guest OS via VIX Error hibát kapjuk a képünkbe. A hiba nem okoz gondot, ha az RPC teszt sikeres.
A Veeam először az RPC-t használja majd próbálkozik VIX-el.
A VIX Vmware hoston keresztül direktbe fér hozzá a vendég oprendszerhez. Tehát ha az RPC teszt sikeres akkor nincs gond. Viszont, ha szeretnénk mindent sikeresnek látni akkor a Vix működésének vannak feltételei. Ilyen, hogy csak local administrator felhasználóval megy, vagy kikapcsolt uac-cal (nem javasolt)

Az itt található táblázatban látszik milyen felhasználóval uac állapottal működik:

table

Windows Defender nem nyílik meg Server 2016-2019-en.

Ha meg szeretnénk nyitni a Windows Defender-t Windows Serveren az alábbi hibaüzenetet kapjuk:

Windows_defender_open_error_Windows_server_2016

“Windows cannot access the specified device, path, or file. You may not have the appropriate permissions to access the item.”

Megoldás az alábbi policy engedélyezése:
Computer Configuration-> Windows Settings-> Security Settings -> Local Policies-> Security Options
Enable:User Account Control: Admin Approval Mode for the Built-in Administrator account

 

SMB1 lenni vagy nem SMB1 lenni

Mostanában megint rendszeresen felmerül, hogy Windows 10 nem tud csatlakozni Nas-okon vagy linux-on található megosztásokhoz. Az SMB1 Windows 1709 óta a különböző verziókba máskép van jelen friss telepítést követően. MS leírás itt:
https://support.microsoft.com/en-us/help/4034314/smbv1-is-not-installed-by-default-in-windows

SMBv1 has the following behavior in Windows 10 Fall Creators Update and Windows Server, version 1709 (RS3):

SMBv1 now has both client and server sub-features that can be uninstalled separately.
Windows 10 Enterprise and Windows 10 Education no longer contain the SMBv1 client or server by default after a clean installation.
Windows Server 2016 no longer contains the SMBv1 client or server by default after a clean installation.
Windows 10 Home and Windows 10 Professional no longer contain the SMBv1 server by default after a clean installation.
Windows 10 Home and Windows 10 Professional still contain the SMBv1 client by default after a clean installation. If the SMBv1 client is not used for 15 days in total (excluding the computer being turned off), it automatically uninstalls itself.
In-place upgrades and Insider flights of Windows 10 Home and Windows 10 Professional do not automatically remove SMB1 initially. If the SMBv1 client or server is not used for 15 days in total (excluding the time during which the computer is off), they each automatically uninstall themselves.
In-place upgrades and Insider flights of Windows 10 Enterprise and Windows 10 Education do not automatically remove SMB1. An administrator must decide to uninstall SMB1 in these managed environments.
Automatic removal of SMB1 after 15 days is a one-time operation. If an administrator re-installs SMB1, no further attempts will be made to uninstall it.
The SMB version 2.02, 2.1, 3.0, 3.02, and 3.1.1 features are still fully supported and included by default as part of the SMBv2 binaries.
Because the Computer Browser service relies on SMBv1, the service is uninstalled if the SMBv1 client or server is uninstalled. This means that Explorer Network can no longer display Windows computers through the legacy NetBIOS datagram browsing method.
SMBv1 can still be reinstalled in all editions of Windows 10 and Windows Server 2016.
Smb1 hiánya miatt felmerülő esetleges hibaüzenetek:

You can’t connect to the file share because it’s not secure. This share requires the obsolete SMB1 protocol, which is unsafe and could expose your system to attack.
Your system requires SMB2 or higher. For more info on resolving this issue, see: https://go.microsoft.com/fwlink/?linkid=852747

The specified network name is no longer available.
Unspecified error 0x80004005
System Error 64

The specified server cannot perform the requested operation.
Error 58

“TCP port is already in use” SQl szerver hibaüzenet 2018.07.10 frissítések telepítését követően

A július 10.-én kiadott windows patch-eknek lehetett egy kellemetlen mellékhatása az SQL service-t illetőn. A frissítés telepítése után Windows Server 2008R2,Windows Server 2012 és R2 valamint Windows 7 és Windows 8.1-en az SQL elérhetetlené vált és TCP port is already in use hibaüzenetet generál. Az Microsoft kiadata azóta a javításokat újra, mely telepítése után már nem jelentkezik a hiba. A hiba mentesek pacth-ek és bővebb hiba leírás itt elérhető: link

Üzemelteti a WordPress.com. , Anders Noren fejlesztésében.

Fel ↑

%d blogger ezt szereti: