Teams-ben létre hozott csoportok nem látszanak az Outlook-ban

Az egyik ügyfél, miután bevezetésre került náluk a Teams, kialakították benne a saját kis csoportjaikat, amiket szeretek volna utána Outlookban is használni. A Microsoft bevezette, hogy alapesetben a Teams-ben létrehozott csoportok nem látszódnak Outlookban, hogy láthatóvá tegyük csatlakozzunk az Exchange online-hoz Powershell -t használva majd hajtsuk végre a következőket:

1, Kérjük le azokat a csoportokat ahol tiltva van, hogy megjelenjenek az Outlookba:

Get-UnifiedGroup |ft DisplayName,HiddenFrom*

2, Engedélyezük, hogy látszódjon a csoport:

Set-UnifiedGroup -Identity “Csoport név” -HiddenFromExchangeClientsEnabled:$false

Set-UnifiedGroup -Identity “Csoport” -HiddenFromAddressListsEnabled $false

 

 

 

 

Office 365 Groups created from Microsoft Teams will be hidden from Outlook by default

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

 

 

Megjelent a Veeam 10 update 1 patch

Megjelent a Veeam 10 első javítása link

A vastagon szedet hiba az egyik ügyfelünknél is jelentkezett:

Javítások listája:

General

• Defragment and compact functionality performs multiple passes on the same full backup for backup jobs that do not use per-VM backup file chains.
• Querying WMI API class “Backup” fails with error code 0x80131500, which affects integration such as Veeam Service Provider Console (formerly Veeam Availability Console).
• Start-VBRInstantRecovery PowerShell cmdlet fails to process restore points created by Backup Copy jobs.
• VCSP rental license point weights were updated according to the March 1st 2020 changes.

NAS Backup

• Copying NAS backups to secondary target erroneously consumes licenses (in addition to licenses consumed by the primary file backup job).

Object Storage

• Capacity Tier copy policy may erroneously upload full backups to object storage periodically when source backup chains do not have periodic fulls.

VMware vSphere

• Resetting CBT on Active Full backup fails if the database contains orphaned ESXi hosts.
• Deleting a vApp from vCloud Director backup may delete the entire backup if backup chain type was recently changed to per-VM backup.

Microsoft Hyper-V

• Hyper-V backup jobs fail the “Object reference not set to an instance of an object” error in environments where at least one virtual machine is stored in the SCVMM Library.
• Replica VMs disk space estimation logic may return incorrect value due to case sensitivity with virtual disk paths, resulting in some disks contributing to the total size twice.

SureBackup

• SureBackup jobs using advanced multi-host virtual labs fail with the “Invalid configuration for device ” error.
• SureBackup log export functionality fails with the “Object was not found” error for SureBackup jobs that include an Application Group.

Tape

• Backup to Tape job skips processing synthetic full backups with forever forward incremental source backup chains on days when full backup file merge happens.

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

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.

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.

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.