Windows Server 2016 RDP lassú bejelentkezés fekete képernyő esetleg a start menü sem működik

start menu not coming up, Server 2016 RDS,DS 2016 – Black Screens and Broken Start Menus

Windows Server 2016 Terminal szerveren előfordul, hogy a szerveren a felhasználó bejelentkezés lassul, sokáig fekete képernyő látható majd a startmenü se működik.
Ezt egy hiba okozza: Minden egyes felhasználó első bejelentkezésekor, jó pár tűzfal szabály létre jön amit az “Appcontainer” hoz létre, viszont ha a user profile-t töröljük, vagy a upd diszket használunk és a felhasználó kilép nem törlődnek le ezek a szabályok és újra belépéskor megint létrejönnek és megint és megint…., mígnem több ezer vagy 10 ezerre nőnek ezek a szabályoka registryben itt:

HKLM\System\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\RestrictedServices\Configurable\System

Ez gy sok felhasználós RDP szerveren, vagy ahol sok ki belépés van pár hét alatt vagy hónap alatt azt tapasztaljuk hogy lassul bejelentkezés, sokáig csak egy egér mutató és fekete háttér lát a felhasználó.
Több megoldás létezik. Az egyik, hogy az itt található Microsoft által készített javasolt scriptet naponta lefuttatjuk ami törli a kilépet felhasználók ott maradt szabályait.

A másik, hogy ha telepítve van a szerverre a 2018. novemberi KB4467684 számú frissítés (ennek azért már illik telepítve lennie), létre kell hozni egy registry kulcsot DeleteUserAppContainersOnLogoff” (DWORD) értéke 1 és kilépéskor törli már ezeket a rendszer. Itt hozzuk létre a kulcsot

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\

 

“Addresses an issue that slows server performance or causes the server to stop responding because of numerous Windows firewall rules. To enable the changes, add a new registry key “DeleteUserAppContainersOnLogoff” (DWORD) on “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy” using Regedit, and set it to 1.”

 

Reklámok

Windows Server in-place upgrade path

Közeleg a Windows Server 2008R2 életének a vége és a cégek is kezdenek felébredni. Nem minden esetben jó az in-place upgrade, de pl. egy sima file server esetén miért ne, főleg, ha több terra adat van rajta?
A Microsoft létrehozott egy upgrade centert, ahol kiválasztva, hogy honnan hova szeretnék eljutni ajánl in-place upgrade útvonalat.
Pl. 2008R2 ugrás 2012 ugrás 2016 ugrás 2019-re, tehát 3 db in place vár ránk.

Microsoft Upgrade Center Link

Certificate SH1 hash migrálássa SH2-re Windows PKI esetén

Az SH1 hash használó certificatek egy ideje nem túl biztonságosak, ezért célszerű az Active directory root , subordinate és a kiállított tanúsítványokat cserélni.

Az alábbi linkek alapján elvégezhető a migrálás:link1, link2

WSUS lefagyogat időnként

Minap ismét előjött, így legyen meg itt is:-), hogy mi a teendő, ha a meglévő wsus fagyogat vagy ha új telepítés egyből állítsuk be az első lépésként.

Asteriksz's Blog

Újra WSUS, ezúttal egy másik környezet, migrálás régi verzióról egy vadiúj Win2016-os rendszerre. A telepítés, beállítások után szépen kezdenek megjelenni a gépek, melyek (utólag kiderült, szerencsére) még nem homogén OS-el rendelkeznek (Win7, 8.1, 10 vegyesen).

Vannak viszont olyan renitens gépek, amelyek megjelennek a listában, de „Not yet riported” státuszban. Mivel nem akartam kapkodni, s volt egyéb dolgom is, hagytam őket ebben az állapotban egy ideig, de pár nap után már kezdtem ferde szemmel nézni rájuk – főleg, hogy a többiek már rég betöltődtek.

Vegyük sorra, mi az, ami közös. Nos, a problémás gépek mindegyike vagy Server2016, vagy W10 1607 (vagy újabb) verzió volt. Mivel minden 2016-os rendszer friss telepítés, ezért értelemszerűen a legújabb – tehát beleesik a fenti szűrőbe. Az egyedüli sikeres Win10-esen 1511-es verzió található – így legalább tudom, hogy nem globálisan a Win10-el van baja. Kézzel kikényszerítve a frissítést, a következő hibaüzenet fogadott:

There were some problems installing…

View original post 185 további szó

Solving the Cached Exchange Mode (CEM) problem for Outlook in stateless virtual workspace sessions the easy way with FSLogix

A couple of weeks ago I was attending a presentation from FSLogix about their App and Profile Containers. One of the solutions is called the Office 365 Container. In short, this is a solution for the Cached Exchanged Mode (CEM) problem in stateless (or non-persistent) virtual workspace sessions.

In this blogpost I will explain how this solution works, what problem it solves and how it’s implemented!

View original post 1 343 további szó

Adobe Reader DC Crashing Windows Terminal Server

Adott volt egy friss telepítésű Windows Server 2016 RDS server amre sajnos szükséges telepíteni az Adobe Reader DC Pdf, olvasó csoda progit. Telepítés után ez a csoda program azzal szórakoztatott, hogy ha pdf file-ra kattintva indítom akkor elindul, ha viszont csak magát a programot indítottam szépen összeomlott. Kiderült, hogy ha elindult egy file segítségével és ha kikapcsolom a protection-t (preferences\security fül) akkor szépen működik ahogy kell. Na most ezt minden egyes terminal server használó felhasználónál meg kell tenni.
Megoldás Group policy + registry buhera, tilthatjuk computer ágon vagy user ágon:

Felhasználó:

Keypath: HKCU\SOFTWARE\Adobe\Acrobat Reader\DC\Privileged

Value name: bProtectedMode

Value type: REG_DWORD

Value data: 0

Computer:

Keypath: HKLM\SOFTWARE\Wow6432Node\Policies\Adobe\Acrobat Reader\DC\FeatureLockDown

Value name: bProtectedMode

Value type: REG_DWORD

Value data: 0

GPO:

 

 

O365 másodlagos fiokból történő küldésnél a levél a postázandóban marad

Minap szükség volt, terminál szerver környezetben az outlook cache módját kikapcsolni.
Ez egy nem várt hibát okozott azoknál a felhasználóknál akik a saját fiokuk mellet share mailbox-nevében is küldenek levelet. A hiba az, hogy a share mailbox nevében küldött levelek lemennek ugyan, de a postázandó mappába ragadnak nem kerülnek az elküldöttbe.
Eegy registry kulcsot is módosítani szükséges.

HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\Preferences
DWORD: DelegateSentItemsStyle
Data Value: 1

Bővebb infók : link   Email remains in the Outbox o365 cache mode off

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

 

 

 

AD és O365

Asteriksz's Blog

Aktuális történetem szintén AD-ról szó, bár ez érdekes módon most Exchange-problémából indult. Igen, természetesen tudom, hogy az Exchange az AD-ra épül – de azért mégis két külön termék.

Adott egy elég nagy szervezet, több tartománnyal, több Exchange kiszolgálóval. Egyes helyeken a levelezést már kiszervezték O365-be, míg más tartományok maradtak a hagyományos Exchange-verziónál (ami ráadásul most van migráció alatt, egy újabb verzió kerül bevezetésre – de jelen esetben ez lényegtelen).

A gond ott merült fel, hogy bizonyos tartományokból nem lehetett másik tartománybeli felhasználóknak emailt küldeni, „A postaláda címzettjének nincs postaláda-adatbázisa.” hibaüzenettel eldobta – s itt most csak a „belső” („testvér”) tartományokra gondolok.

Szokás szerint a helyzet nem volt ennyire egyszerű, ugyanis első információk szerint csak egy tartomány volt, amelyik nem tudott a cél-tartományba küldeni, miközben minden más irányba csont nélkül kimentek a levelek.

Kezdjük az elejével. A hibaüzenet alapján látszott, hogy a cél-tartományban (amelyik ráadásul O365-be költözött) nem történt…

View original post 390 további szó