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.
Ez rányomja a bélyegét az újdonságokra is, sok a felhőből jön
Sok minden viszont ment a levesbe:
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.
Egyenlőre kimaradt, de jön:
Ami maradt:
Természetesen az on-prem, nem felhős változatokról van szó.
A bejelentések:
Most bukkantam rá, hogy az SfB network assessment tool, már Microsoft Teams kapcsolódási teszteket is tartalmaz.
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.
… mindenképpen tegyétek fel az alábbi update-t:
https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2018-8340
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
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
}
}
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'"
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.
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.
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:
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:
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:
Mindez PowerShell-ből:
Set-ADUser user@cegnev.hu -Replace @{'PreferredLanguage'="en-US"}
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.
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.
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.
|
A ZOMPUTER vezetője vagyok, rendszermérnök, a kezdetektől, 2009 óta foglalkozom a Microsoft felhőszolgáltatásaival. Több száz ügyfélnél összesen több mint 50 ezer felhasználó felhős bevezetésében vettem részt a világ 25 országában. Rendszeresen tartok felhős előadásokat a partnereknek. 2010 óta vagyok Office 365 MVP, amely címmel a világon 3.-ként tüntettek ki. |
