aj keď ju spúšťame na fyzickom počítači. Dôvodom je zapnutá virtualizácia no a ide teraz len o to, že ktorá. Skúsil som vypnúť virtualizáciu pamäte, ktorú Windows používa na zvýšenie bezpečnosti operačného systému. Prístupná cez Nastavenia – Aktualizácie a zabezpečenie – Windows zabezpečenie – Zabezpečenie zariadenia – Izolácia jadra – Možnosti – vypnúť Integritu pamäte
Odinštaloval podporu virtualizácie vo Windows cez Súčasti systému Windows a odškrtnutím platformy hypervízora Windows a podpory virtuálneho počítača:
ale nakoniec reálne zabralo až vypnutie podpory virtualizácie v BIOS-UEFI. Teda Nastavenia Windows – Aktualizácie a zabezpečenie – Obnovenie – Rozšírené spustenie – Reštartovať
Po reštarte ideme v menu do riešenia problémov/troubleshoot – rozšírených možností – Nastavenia UEFI/BIOS
Tam to závisí podľa výrobcu, ale hľadáme položku virtualizácia, ktorú prepneme na Disabled. Ja si pomôžem ilustračným obrázkom z internetu a vy si pomôžte manuálom od výrobcu základnej dosky, kde sa dozviete kde sa táto položka nachádza vo vašom UEFI/BIOSE a ako sa volá:-)
Začneme pridaním disku na ktorý chceme queue presúvať. Disk by mal byť naformátovaný ako NTFS so 64k block size.
Na presun queue použijeme skript, ktorý je súčasťou inštalácie Exchange. Teda presunieme sa do adresára s Exchange skriptami typcky umiestnenom v C:\Program Files\Microsoft\Exchange Server\V15\Scripts (alebo cez príkaz – cd $ExScripts). Skript sa volá Move-TransportDatabase.ps1
Queue máme typicky umiestnenú na disku C: v adresári C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\data
Po spustení skriptu cez Exchange powershell pustený ako administrátor sa udeje prepočet voľného miesta na cieľovom umiestnení podľa veľkosti aktuálnej databázy, vytvorenie novej adresárovej štruktúry, zastavenie Microsoft Exchange Transport service, vytvorenie zálohymkonfiguračných súborov, presun súborov a nakoniec spustenie Microsoft Exchange Transport service. Skript je potrebné paramatrizovať. V príklade rátame s tým, že nový queue máme na disku Q:
Po skončení si skontrolujeme čí na novom disku je presunutá databáza – mail.que a trn.chk ako aj transakčné logy trn.log, trntmp.log, trnres00001.jrs, trnres00002.jrs a tmp.edb.
V pôvodnom umiestnení queue (C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\data\Queue) si nám vznikla záloha. To si môžeme odložiť a zmazať.
V adresári C:\Program Files\Microsoft\Exchange Server\V15\Bin nájdeme dva súbory s názvom EdgeTransport.exe.config. Jeden je záloha s pôvodnými paramatrami umiestnenia queue a druhý aktuálny. Zaujímajú nás riadky QueueDatabasePath, QueueDatabaseLoggingPath, IPFilterDatabasePath, IPFilterDatabaseLoggingPath, TemporaryStoragePath.
Po presune queue spravíme ešte jednu drobnú zmenu a to zmenu mazania presunutého adresára pre UnifiedContent, ktorý sa nachádza v C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\data\Temp\UnifiedContent na nový disk, v našom prípade Q:\TransportRoles\data\Temp\UnifiedContent.
Robí sa to zmenou xml súboru – Antimalware.xml v ceste C:\Program Files\Microsoft\Exchange Server\V15\Bin\Monitoring\Config. Spravíme si zálohu a editujeme (ako admin) riadok CleanupFolderResponderFolderPaths, kde starú cestu C:\Program Files…. nahradíme novou a reštartujeme službu Exchange Health Manager service
Microsoft niekedy v polovici roka 2023 zmenil spôsob ako sa systémy využívajúce Windows Recovery Environment aktualizujú cez Windows Update a WSUS. Pri niektorých systémoch sa môže stať nemajú dostatočne veľkú recovery partíciu a aktualizácia takéhoto operačného systému končí s chybou 0x80070643.
Samozrejme že najprv vyskúšame vstavaný troubleshooting vo Windows pre aktualizácie, a pár osvedčených iných spôsobov, ale keď sa nikde nedopracujeme budeme musieť pristúpiť k rozšíreniu tejto partície. Nie je to síce ťažký úkon, ale pre bežného používateľa pomerne nepriateľský. Robíme to totiž cez príkazový riadok, konkrétne utilitku diskpart.
Teda naštartujeme príkazový riadok ako administrátor a zadáme príkaz reagentc /info cez ktorý si overíme či používame Windows Recovery Environment (WinRE). Z výstupu nás zaujíma najmä číslo harddisku a partície, keďže s nimi budeme ďalej pracovať.
Zastavíme službu WinRE reagentc /disable a spustíme diskpart
Prvým ktorom je ukrojiť z partície kde nám beží operačný systém a pripraviť si prostredie na vytvorenie novej recovery partície:
list disk
vyberieme disk z príkazu vyššie teda napr. sel disk 1
vylistujeme partíce cez list part a vyberieme primary partition cez sel part 4 , čo je poradové číslo v našom prípade
zredukujeme ho o 250MB príkazom shrink desired=250 minimum=250
teraz vyberieme recovery partition podľa indexu z prvého príkazu, teda v našom prípade 1 – sel part 1 a zmažeme ju príkazom delete partition override
Hádam len také jemné upozornenie – dávajte si pozor čo robíte a ktorý disk máte aktuálne vybraný, nech si nepomažete disky s dátami.
Ďalším krokom bude vytvorenie a naformátovanie novej recovery partície. Pre GPT disk (to je tá hviezdička v obrázku vyššie) použijeme príkazy:
Samozrejme máme nejakého používateľa v skupine Administrators, proste sa ako Admin nechová a Windows nevieme prinútiť aby sa začal. Riešením je prihlásenie sa do Safe mode, resp. jeho command line a spustenie príkazu na zaradenie opätovné toho používateľa do skupiny Administrators. Alebo iného teda ak chceme.
Safe mode zapneme cez GUI – Nastavenia – Aktualizácie a zabezpečenie – Obnovenie – Rozšírené spustenie – Reštartovať, alebo príkazom shutdown /R /O -T 0
Keď nabehne štartovacia obrazovka s recovery možnosťami vyberieme Riešenie problémov (Troubleshoot) – Advanced options – Startup settings – Restart a potom z voliem vyberieme 6 – enable safe mode with command prompt.
Keď naštartuje Windows prihlásime sa aktivovaným vstavaným účtom Administrators (bez hesla) a pustíme nasledujúce príkazy
net localgroup Administrators Nazov_uctu_nasho_admina /Addnet user Nazov_uctu_nasho_admina /active:yes
Obligátny reštart shutdown /R -T 0 a UAC by nám už malo fungovať normálne.
Ak nás SharePoint privíta opakovaným dialógom na zadávanie hesla a končí to buď bielou stránkou alebo chybou 401 (ak nevypíše zistíme to napríklad cez developer tools) dôvodov môže byť viacero.
Určite je dobré skontrolovať si Alternate Access Mappings v centrálnej administrácii v aplikačnom manažmente, v IIS zase skontolujeme bingingy a Authentication setting, kde pozrieme nastavenie Authentication Providers (NTLM, Kerberos…) prípadne skontrolujeme ako máme nastavené Enable Kernel mode authentication v Advanced Settings.
Ak nič nepomáha, resp. máme to nastavené všetko tak ako má byť, skontrolujeme si ešte nastavenie overovania vo Windows-e. Ak používame overovanie cez NTLM, politika Network Security: LAN Manager authentication level by nemala byť nenakonfigurovaná. Tu si nastavme minimálne podporu NTLMv2.
Ďalej je vhodné skontrolovať si nastavenie registrov pre DisableLoopbackCheck (DWord) vo vetve HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
To by sme mali mať nastavené na hodnotu 1, teda vypnuté. Podľa odporúčaní Microsoft-u toto nastavenie by sme nemali používať v produkcii z dôvodu zníženia bezpečnosti. Používať by sme mali string BackConnectionHostNames vo vetve Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0, kde by sme mali zadať adresu našej Sharepoint stránky. Na skúšku či problémom je toto nastavenie je určite rýchlejšie hrať sa s 0 a 1 pri DisableLoopbackCheck.