Zomby blogja

Sharepoint 2019 újdonságok

A saját szemszögemből fontosnak talált összegzés. Alapvetőleg a felhős tudás került bele a helyi változatokba, de természetesen vannak újdonságok is. A SharePoint 2019 főleg a felhős tudást hozza el on-prem.

  • Nem változott a fejlesztési metódus, mint az Exchange-nél:

    Ez rányomja a bélyegét az újdonságokra is, sok a felhőből jön

  • Modern Team site-ok, Library-k, listák, lapok
  • Egyszerűbb site létrehozás
  • OneDrive Sync kliens használat Sharepoint dokumentum könyvtárakkal
  • Mobil kliens is!
  • Search
  • Workflow support, a felhős PowerApps-al és Flow-al is. (szükséges hozzá gateway)
  • Egyszerűbb Hybrid
  • SMTP szerver authentikáció (itt volt nagyon az ideje)
  • # és % karakter támogatott a fájl és mappanevekben
  • 400 karakteres maximum URL
  • 25% gyorsabb fájl műveletek
  • IIS6 függőségek nincsenek már
  • Mások által törölt fájlok is visszaállíthatók a kukából
  • Windows Server 2016/2019 , SQL Server 2016/2017 támogatott

 

Sok minden viszont ment a levesbe:

Exchange 2019 újdonságok

Megpróbálom a saját szemszögemből fontos dolgokat összegezni. Alapvetőleg a felhős tudás került bele a helyi változatokba, de természetesen vannak újdonságok is.

  • Windows Server 2019-re kell telepíteni, sőt javasolt core-ra.
    Véleményem az, hogy ez utóbbi jó serurity szempotjából, viszont kihívás üzemeltetni. Nem is az Exchange PowerShell miatt, eddig is kizárólag PS-ből konfiguráltam, de a szerver hardver konfigurációja sokszor nagyon macerás parancssorból. Helló HP ACU!
  • SSD diszkekkel jelentősen gyorsítható a keresés, sőt javasolt a használatuk. (Eddig ez nem így volt)
    De csak a MetaCache adatbázist (Index, mappastruktúra, kis elemek, kb. 10%) kell SSD-n tartani, a többi továbbra is JBOD, ami akár lehet olcsó SATA is.
    Az üzenet: használj SSD-t és JBOD-t

  • Ez a kép sokat elmond a jövőbeli fejlesztésről:

    Eddig ugyanaz volt a kódbázis az Online verzióval, most már egy párhuzamos ágon megy a fejlesztés

  • UM (voicemail) ment a levesbe, ehhez már kell a felhő vagy külső telefon rendszer. Őszintén szólva én eddig sem láttam nagy pluszt benne.
  • TLS 1.2 kell legalább (ez a klienseket bekorlátozza )
  • Edge Szerver újra!
  • minimum javasolt memória a mailbox szervereken 128 Gb (64 Gb az edge-n), 256 Gb max.
  • Indexelés teljesen megváltozik – Bingből jön. Bekerül az adatbázisba, aktuálisan a felhasználó postaládájába. Bekerül a log replikációba is.
  • A passzív adatbázisok, már sokkal kevesebb memóriát használnak. Így 20%-al több felhasználó fér egy szerverre, kisebb késleltetés, nagyobb diszkeket lehet használni.

  • Remove-CalendarEvents végre on-prem is. (Egy felhasználó összes meetingje törölhető)
  • OWA-val létrehozható olyan megbeszélés, amit nem lehet továbbítani, új OOF funkciók, pl. ha valaki küld a szabira meeting request-et, automatikusan elutasítódik
  • Nem angol karakteres email címek támogatása (ki szívatja ezzel magát ?)
  • n-2 -es együttműködés a régebbi Exchange Server és Outlook változatokkal. Szóval Exchange 2013+, Outlook 2013+ támogatott csak.

Egyenlőre kimaradt, de jön:

  • nincs még adatbázis kalkulátor
  • Az Exchange tudja, de a kliens oldal még nem, tehát még nem tudjuk használni: Modern-Auth
  • Mailbox titkosítása az adatbázison belül

Ami maradt:

  • Adatbázis (DAG) struktúra

Megjelent a Sharepoint és az Exchange Server 2019


Természetesen az on-prem, nem felhős változatokról van szó.

A bejelentések:

SharePoint 2019

Exchange 2019

Microsoft Teams hálózati teszter

Most bukkantam rá, hogy az SfB network assessment tool, már Microsoft Teams kapcsolódási teszteket is tartalmaz.

Letöltés

Doksi

Office 365 IP címek és tartományok

Ezzel már tesztelni lehet a Teams hívások és megbeszéléseken használt ip címeket és portokat. Tehát tesztelhetitek, hogy a tűzfalatok jól van-e beállítva. Automatikusan frissíti is az ip címeket, ha később változik.

 

Ha ADFS szervert használtok …

… mindenképpen tegyétek fel az alábbi update-t:

https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2018-8340

Windows 1803 lefagy a boot logónál

Több gépen fordult elő nálunk, hátha valakinek segít.

A 1803 frissítés telepítése után újraindul a gép, eljut a boot logóig, aztán lefagy. Csak kikapcsolni lehet, ekkor visszakerül az előző Windows változat.

Persze többször is megpróbálja a Windows frissíteni magát, de az eredmény minden alkalommal ugyanaz.

A megoldás: VT-d -t ki kell kapcsolni a BIOS-ban. 

Disable a helyes beállítás

Office 365 IP címek lekérdezése PowerShell-ből

Több ügyfélnél előfordult már, hogy szeretnék a tűzfal beállításokhoz automatizálva letölteni az ip címeket. Erre azért van szükség, mert pl. az Exchange Online Protection-hoz csak az Office 365 felé szeretnék kinyitni a tcp/25 -ös portot. Ebben az esetben így néz ki a forgalom:

 

A tűzfal konfigurációhoz az alábbi PowerShell-el tölthetőek le a címek:

$updateUrl = "https://support.content.office.net/en-us/static/O365IPAddresses.xml"
$productName = "EOP"
try {
$ipList = New-Object System.Xml.XmlDocument
$ipList.Load($updateUrl)
catch {
Write-Host "Cannot download file $updateUrl" -ForegroundColor Red
break
}
if (-not ($ipList.ChildNodes.NextSibling)) {
Write-Host "Cannot process XML file $updateUrl. " -ForegroundColor Red
break
}
foreach ($prod in ($ipList.products.product | ? {$_.Name -match $productName} | Sort-Object Name)) {
$ip4Ranges = $prod | Select-Object -ExpandProperty Addresslist | Where-Object {$_.Type -match "IPv4"}
$ip4Ranges = $ip4Ranges | ? {$_.address -ne $null} | Select -ExpandProperty address
foreach ($ip4Range in $ip4Ranges) {
$res = New-Object -TypeName psobject -Property @{
'Product'=$prod.Name;
'IPv4Range'=$ip4Range;
}
$res | Select -ExpandProperty IPv4Range
}
}

Microsoft Teams: Igazi vendég hozzáférés

Sokszori késés után végre megjelent a Teams-ben az "igazi" vendég hozzáférés. Eddig is lehetett vendégeket-külsösöket felvinni, de csak olyanokat, akiknek volt Azure Active Directory (AAD) hozzáférésük, tehát iskolai vagy céges Office 365 fiókjuk.

A vendég hozzáférés azért fontos, mert sokszor előfordul, hogy egy csapatnak együtt kell dolgoznia külsösökkel is. Sőt nálunk például ez inkább a tipikus. Ha már működik, bárki akinek email címe van vendégként szerepelhet, sőt még Microsoft Account sem szükséges hozzá, az Azure B2B Collaborationt fogja használni. A többi alkalmazás, pl. a SharePoint már ezt használja, ha van meglévő felhasználó, akkor a Teams is ugyanazt a fiókot fogja használni.

Egyenlőre a mi előfizetésünkben még nincs aktiválva, még szerepel a céges fiók igény:

Ez az alábbira fog változni:

Az új vendég egy meghívót fog kapni, amely végigvezeti a teendőkön.

 

Amennyiben szeretnétek látni mi folyik az AAD színfalak mögött, az alábbi PowerShell parancsokkal kérdezhető le a vendég felhasználók listája:

Import-Module AzureAD
Connect-AzureAD
Get-AzureADUser -Filter "UserType eq 'Guest'"

Exchange 2016 PowerShell ISE parancsokkal

Ha egy _Exchange szerveren_ szeretnétek, hogy a PowerShell ISE rögtön tudja az Exchange parancsokat indulás után a következőt kell tenni. Indítsatok egy normál PowerShell ISE ablakot és copy&paste az alábbi parancsokat:

$tofile=@'
Function Test-Command ($Command)

{
Try
{
Get-command $command -ErrorAction Stop
Return $True
}
Catch [System.SystemException]
{
Return $False
}
}
IF (Test-Command "Get-Mailbox") {Write-Host "Exchange cmdlets already present"}
Else {
$CallEMS = ". '$env:ExchangeInstallPath\bin\RemoteExchange.ps1'; Connect-ExchangeServer -auto -ClientApplication:ManagementShell "
Invoke-Expression $CallEMS
}
'@

if (!(Test-Path -Path $PROFILE ))
{ New-Item -Type File -Path $PROFILE -Force;$tofile|Out-File $PROFILE }

Ezután az ISE-t indítva rögtön elérhetőek az Exchange parancsok.

Office 365 Planner újdonságok

A Planner egy feladat nyilvántartó csapatoknak, amely nemcsak a webes felületen, de a Planner alkalmazásban mobilon is elérhető. Nagyon egyszerűen és gyorsan feladatokat tudunk feldobálni és csoportosítani, kollégákhoz rendelni.

A Microsoft tette közzé a legújabb funkciókat:

Ütemezés nézet (Schedule view). Ez nézet a feladatokat mutatja egy naptáron, ahol fogd és vidd módszerrel dobálni lehet a feladatokat. Van heti és havi nézet is.

Ezen kívül bekerültek új csoportosítási és szűrési opciók. Pl. meg lehet jeleníteni a nem elkezdődött vagy be nem fejeződött feladatokat vagy kiszűrni azokat amelyek egy adott időpontban járnak le.

 

Ezenkívül kérhetünk még a következő héten lejáró feladatokról email értesítést.

Az új funkciók, mától elérhetőek a Plannerben.

Egyirányú Free-Busy hibrid Office 365 konfigurációban

Egy ügyfél keresett meg, hogy az eddig működő naptár foglaltság egyszer csak egyirányú lett. A felhős felhasználóknál látszik a naptár foglaltság, azonban ha a helyi felhasználók naptár foglaltságát szeretnék megnézni a felhős felhasználók, nem mutat semmit, "nincs információ" (no information).

Mivel a konfiguráció elég bonyolult is lehet, először a felhős OWA-val kezdtem, utóbb ez szerencsésnek bizonyult. Egy teszt felhasználó levelezésében az új naptáresemény fülön elindítottam az Ütemezési asszisztenst:

Ennek segítségével meg lehet nézni egyszerűen bárki foglaltságát. De nem ez érdekelt, hanem hogy miért nem működik. Az IE-ben F12-vel lehet előhozni a fejlesztői eszközöket és itt a hálózat "network" fülön láthatjuk, hogy az IE milyen kéréseket adott fel és mi volt a válasz. Megjegyzés: pl. Fiddler-el is lehetne nézni, de az IE első körben egyszerűbb.

Ha elindult az alsó részen a fejlesztői eszköz, akkor adjuk hozzá a helyi (on-prem) felhasználót a résztvevőkhöz. Itt megkapjuk, hogy "nincs információ", de erre is számítottunk.

Viszont azonban a hálózati forgalomban visszagörgetünk alulról és megkeressük a "GetUserAvailabilityInternal" lekérést és a jobb oldali részen a Body-ra váltunk láthatjuk a hibaüzenetet, egy kép többet mond mit száz szó:

A hibaüzenet:

Autodiscover failed for email address user@domain.hu with error Microsoft.Exchange.InfoWorker.Common.Availability.AutoDiscoverFailedException: The response from the Autodiscover service at 'https:\/\/autodiscover.domain.hu\/autodiscover\/autodiscover.svc\/WSSecurity' didn't return a valid value for user setting 'ExternalEwsUrl'

 

Tehát nem tudta lekérdezni a külső EWS címét. Furcsa. Megnézve a helyi Exchange szerveren az EWS külső címét PowerShell-el ezt kaptam:

Get-WebServicesVirtualDirectory |Select name, *url | fl

Name : EWS (Default Web Site)

InternalNLBBypassUrl :

InternalUrl : https://mail.domain.local/EWS/Exchange.asmx

ExternalUrl :

Igen jól látszik, hogy nem látszik. Semmi sincs beállítva külső External URL-nek. Persze mindenki tagadott, de valaki azért elállította…

A javítás innen már egyszerű, vissza kell állítani az eredeti állapotot:

Get-WebServicesVirtualDirectory | Set-WebServicesVirtualDirectory -ExternalUrl https://mail.domain.hu/EWS/Exchange.asmx

Az IIS újraindítása után (iisreset) máris látszanak a foglaltság adatok:

 

Office 365 portál nyelv megváltoztatása hibrid környezetben

Nem nagy dologról van szó, viszont adott esetben annál bosszantóbbról. Mi a helyzet akkor, ha hibrid Exchange környezetet használunk, de pl. magyarul jelenik meg minden, nem csak a normál portál, de az pl. admin portál, az Exchange admin center és az owa is. A teljes lista:

  • Office 365 alapoldal
  • Általános beállítások és menü
  • Office 365 Admin portál
  • ECP
  • Video
  • Groups
  • OneDrive for Business
  • Delve
  • Office Online
  • Planner

Nem hibrid esetben ez nem gond át lehet állítani, a felületen:

Azonban ez a menüelem a szinkronizált felhasználóknál egyszerűen hiányzik:

A megoldás az, hogy a helyi AD-ban a felhasználóhoz tartozó preferredLanguage attribútumot átállítjuk.

Active Directory Users and Computers-ben be kell kapcsolni a View/Advanced Features-t

Ezután a felhasználó tulajdonságait megnyitva megjelenik az Attribute Editor fül:

Ezután lehet átírni a preferredLanguage attribútumot:

A nyelvi kódok listája

Mindez PowerShell-ből:

Set-ADUser user@cegnev.hu -Replace @{'PreferredLanguage'="en-US"}

Megosztott postaláda: levél másolat a küldött elemekről a postaládában

A megosztott postaládák alapból úgy működnek az Office 365-ben, hogy csak a küldő postafiókjába kerül bele a levél az elküldött elemek közé, a megosztott postaládába nem. Tehát a többi felhasználó nem látja az adott megosztott postaládából küldött leveleket, csak a küldő a saját postafiókjába.

A megoldás, hogy Exchange Online PowerShell segítségével átállítjuk ezt a beállítást:

Get-Mailbox megosztottpostafiok | Set-Mailbox -MessageCopyForSentAsEnabled $true -MessageCopyForSendOnBehalfEnabled $true

Létezik egy registry kulcs (DelegateSentItemsStyle), amivel az Outlookban átállítható ez a működés, de az csak az adott helyi Outlookra vonatkozik, pl. OWA-ra nem, ráadásul az összes felhasználónál egyenként kell állítani. Ahhoz, hogy a szerver oldali beállítás legyen érvényes, ezt le kell tiltani (alapból le van tiltva az Outlookban).

SentAs: Küldés a fiók nevében.

SendOnBehalf: Küldés a fiók nevében úgy, hogy kifelé látszik az eredeti küldő is.

Felhasználói tanúsítvány Subject Alternative Name lekérdezése PowerShell -ből

Egysoros, hogyan lehet lekérdezni az aktuális felhasználó az adott "ENTERPRISE CA" által kiadott "User" tanúsítványából a Subject Alternaive Name tulajdonságot:

($(gci Cert:\CurrentUser\My|?{$_.Issuer -like "*ENTERPRISE CA*"}).Extensions|?{$_.Oid.FriendlyName -eq "subject alternative name"}).Format(1)

Arra jó, hogy ellenőrizzük van-e a felhasználónak tanúsítványa és milyen accountra lett kiállítva. Az "ENTERPRISE CA" értéket át kell állítani a saját CA-nk nevére.

Ha hibaüzenetet kapunk, mint alább, akkor vagy nem jó a CA neve vagy nincs kliens tanúsítvány.

You cannot call a method on a null-valued expression.

Always On VPN problémák

For English readers: You can find the English version under the Hungarian one.

Követve a dokumentációt, két pofonba lehet rögtön beleszaladni.

Az első:  VPNUserAuthentication template could not find specified CSPs
Ha beállítjuk a fenti dokumentáció szerint a CA template-t és egy olyan gépen futtatjuk, ahol nincs TPM chip (például virtuális gép), akkor nem fog létrejönni a felhasználó tanúsítványa. A CertificateServicesClient-CertEnroll kliens sajnos alapból nem loggol semmit, úgyhogy még hibaüzenet sem lesz.
Az első teendő, hogy kapcsoljuk be a loggolást.
A registryben a HKLM\Software\Microsoft\Cryptography\Autoenrollment kulcs alatt hozzunk létre egy AEEventLogLevel DWORD bejegyzést, aminek 0 az értéke.
Ezután adjuk ki a gpupdate /force /target:user parancsot. (Nem szükséges újraindítás)
Az Event Viewer-ben nyissuk meg az Application Log-ot és megtaláljuk a következő hibaüzenetet:

Log Name: Application
Source: CertificateServicesClient-CertEnroll
Event ID: 55
Level: Warning
Certificate enrollment for DOMAIN\user for the VPNUserAuthentication template could not find specified CSPs on the local machine. Enrollment will not be performed.

Beszédes, nem?
(A CSP a Cryptographic Service Provider rövidítése)

Szerencsére van egy kis támpont, a dokumentációban, ez szerepel:

Microsoft Platform Crypto Provider lets you use the Trusted Platform Module (TPM) on client computers to secure the certificate.

On the Cryptography tab, complete the following steps:
In Provider Category, click Key Storage Provider.
Click Requests must use one of the following providers.
Select the Microsoft Platform Crypto Provider check box


Tehát csak akkor jön létre a cert, ha van TPM chip a gépben. A megoldás az, hogy megszerkesztjük a VPN User Authentication Template-t:
A certificate szerver kezelőjében jobb gomb a Certificate Templates mappán és Manage. Szerkeszük meg a VPN User Authentication template-t úgy, hogy a Cryptograpy alatt így nézzen ki:

A másik probléma, hogy a VPN Szerver tanúsítványának kérésekor az alábbi hibaüzenetet kapjuk: CERTSRV_E_TEMPLATE_DENIED

The permissions on the certificate template do not allow the current user to enroll for this type of certificate.
Denied by Policy Module
The permissions on the certificate template do not allow the current user to enroll for this type of certificate. 0x80094012 (-2146877422 CERTSRV_E_TEMPLATE_DENIED)
The request ID is 21.

Az ok: Azért fordul elő ez a hiba, mert tényleg nincs jogosultságunk. Ugyan hozzáadtuk a szervert a VPN Servers csoporthoz, de ahhoz, hogy a csoporttagságot felvegye a gép, újra kell indítani, ugyanis a windowsban a csoporttagságok bejelentkezéskor rendelődnek hozzá a tokenhez. Nincs ez máshogy a számítógép fióknál sem, azonban a gép csak induláskor jelentkezik be.

A megoldás: Újraindítjuk a VPN szervert és újrakéjük a certificatet.

________________________________________________________

English version

When you follow the Always On VPN documentation, you can run into the following issues.

ISSUE1: VPNUserAuthentication template could not find specified CSPs

If you set the User CA template according to the documentation and your computer doesn't have a TPM chip (running on VM for example), then the user certificate will not be created. Unfortunately, the CertificateServicesClient-CertEnroll doesn't log anything. First, set  new registry key to turn on more detailed autoenrollment auditing: In HKCU\Software\Microsoft\Cryptography\Autoenrollment, create a new DWORD value named AEEventLogLevel and set its value to 0.

Open up Application Log in Event Viewer (eventvwr.exe).

Force Autoenrollment:

gpupdate /force

In the Application event log, refresh the log to see what happens during autoenrollment.

Log Name: Application
Source: CertificateServicesClient-CertEnroll
Event ID: 55
Level: Warning
Certificate enrollment for DOMAIN\user for the VPNUserAuthentication template could not find specified CSPs on the local machine. Enrollment will not be performed.

CSP means: Cryptographic Service Provider

Luckily in the documentation we can find the following:

Microsoft Platform Crypto Provider lets you use the Trusted Platform Module (TPM) on client computers to secure the certificate.

On the Cryptography tab, complete the following steps:
In Provider Category, click Key Storage Provider.
Click Requests must use one of the following providers.
Select the Microsoft Plaform Crypto Provider check box

So the certificate is only created if the computer has a TPM. The solution is to edit the VPN User Authentication Template.

On the CA, open Certification Authority.
In the navigation pane, right-click Certificate Templates, and click Manage, edit VPN User Authentication and select the Cryptography tab:

Add the Microsoft Software Key Storage Provider.

ISSUE2: CERTSRV_E_TEMPLATE_DENIED
The VPN Server certificate when you try to enroll, you get the following message:

The permissions on the certificate template do not allow the current user to enroll for this type of certificate.
Denied by Policy Module
The permissions on the certificate template do not allow the current user to enroll for this type of certificate. 0x80094012 ( -2146877422 CERTSRV_E_TEMPLATE_DENIED )
The request ID is 21.

The solution: This is happens, because we added the computer to VPN Servers group – and set the permissions on the template to it -, but we didn't restarted the server. Restart the VPN server and try to Enroll again.

Tartalom átvétel