Blogok

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.

US és Magyar billentyűzet beállítás PowerShell segítségével

Windows Server Core -on hasznos lehet, ha váltani szeretnénk a billentyűzetek közül. Mivel nyelvi beállítások nincsenek, marad a PowerShell:

Set-WinUserLanguageList $(New-WinUserLanguageList -Language "en-US"| % {$_.add("hu-HU");$_}) -force

(You can set multiple keyboard languages from PowerShell this way on Windows Server Core)

Wannacrypt, XP, Windows 2003 patch

Nem Office 365-ös téma, de sokakat érinthet az igazándiból SMBv1 patch. A Wannacrypt az eddigi leggyorsabban terjedő kripto vírus (randsomware), elég egyetlen számítógépre eljutnia, hogy utána a hálózatra kötött többi eszközt is megfertőzze, amelyik védtelen.

A megoldás egy Márciusban kiadott hibajavítás: Microsoft Security Bulletin MS17-010

Azonban ez nem minden rendszerre jött ki, viszont tegnap (ma) a Microsoft kiadott egy hibajavítást az Windows XP, Windows 2003, Windows 8 gépekre is:

https://blogs.technet.microsoft.com/msrc/2017/05/12/customer-guidance-for-wannacrypt-attacks/

Az angol nyelvű javításokat direktben innen lehet letölteni:

Windows Server 2003 SP2 x64, Windows Server 2003 SP2 x86, Windows XP SP2 x64, Windows XP SP3 x86, Windows XP Embedded SP3 x86, Windows 8 x86, Windows 8 x64

A Magyar és egyéb nyelveket pedig innen:

http://www.catalog.update.microsoft.com/Search.aspx?q=KB4012598

Exchange Online PowerShell többfaktoros azonosítással (MFA)

Gyors megoldás sietősöknek: kattintás ide

Eddig az Exchange Online-hoz nem lehetett Modern (ADAL, MFA) autentikációval csatlakozni. Nemrég megjelent egy technet cikk, ami részleltesen leírja a csatlakozás folyamatát:

Admin Portal/Admin Centers/Exchange/Hybrid/Configure gomb a Exchange Online PowerShell Module alatt.

Ezután Connect-EXOPSSession -UserPrincipalName <UPN> parancsot kell kiadni és már benni is vagyunk. (az UPN általában az email címmel egyezik meg)

Miután már fel van telepítve a modul az adott felhasználónak, PowerShell ISE -ből az alábbi módon lehet betölteni az Exchange Online PowerShell module -t , hogy működjön az MFA.

Import-Module $((Get-ChildItem -Path $($env:LOCALAPPDATA+"\Apps\2.0\") -Filter Microsoft.Exchange.Management.ExoPowershellModule.dll -Recurse ).FullName|?{$_ -notmatch "_none_"}|select -First 1)
$EXOSession = New-ExoPSSession
Import-PSSession $EXOSession

Elérhető a németországi adatközpontban is az Office 365


 

A különbség főleg az üzemeltetésben van, az adatvédelmi szempontok miatt. Ellentétben az eddigi európai adatközpontoktól, a németországi adatközpontot nem a Microsoft, hanem egy külső cég a T-Systems üzemelteti, így a szigorúbb Német vagy Európai adatvédelmi szabályozás alá eső cégeknek is elérhetővé válnak a felhős szolgáltatások. A Microsoft a technológiát adja, hozzáférése nincs az adatközponthoz. A szolgáltatás elnevezése Office 365 Germany lesz. Az adatközpontok Frankfurt/Main illetve Magdeburgban találhatóak.
Azonban ára is van a biztonságnak, a 4,20 EUR/felhasználó/hó díjú Vállalati alapcsomag 5,30 EUR-ba kerül.

forrás:
Microsoft
fixmibug

Fájl átnevezés Excel Online vagy Word Online-ban

Amikor Office Online-ban új üres fájlt hozunk létre, akkor automatikusan kap egy nevet, például: Munkafüzet, Document5, Presentation, …

Ha a Fájl/Mentés másként menüt használjuk, akkor új fájl jön létre és az üres is megmarad egy új fájl létrehozásakor ez nem a legjobb. A legegyszerűbb átnevezni a dokumentumot.

Ehhez egyszerűen csak a böngésző felső részén a fájlnévre kell kattintani:

Persze be is lehet csukni és átnevezni, de az több kattintással jár. Fájl/Átnevezés funkció egyenőre nincs. (2016.12.18)

Ha már itt tartunk az Office Online-ban nincs mentés funkció, a dokumentumok automatikusan mentődnek minden változáskor.

Tartalom átvétel