| O co jde? No máte SharePoint statek (američani tomu říkají farma, ale jsme v česku, ne?). To znamená více serverů a na každém několik různých služeb a IIS aplikačních fondů (app pool). Každý správně běží pod jiným uživatelským účtem. Tzv. managed service account.
A teď si představte, že někde něco nestartuje, protože to má špatné heslo. Nejhůř, když vám nestartuje SharePoint Timer Service (owstimer), tedy ten, který dělá všechny konfigurace. Takže když uděláte změnu v nastavení, na tom serveru se to ani nemůže promítnout, protože není kdo by to nastavil.
Rychlý postup opravy
- Předpokládám, že máte větší statek a že vám alespoň jeden z těch serverů "tak nějak pracuje".
- Na poškozeném serveru zajistíme, aby se Windows služba SharePoint Timer Service rozjela. To bude nejspíš vyžadovat ručně nastavit v konzoli services.msc její heslo. Tedy pokud opravdu nestartuje, že :-)
- Pokud heslo farm account neznáte, můžete ho zjistit z IIS na serveru, na kterém máte Central Administration, pomocí příkazu APPCMD LIST APPPOOL viz můj článek o vykrádání hesel. Také apppooly služeb Security Token Service a Topology Service běží ve výchozím stavu pod farm account.
- Na to, aby se ta služba připojila do konfigurační databáze, potřebuje mít v registrech správně nastavenu tzv. passphrase. Už jsem o ní něco psal tady. Tedy heslo, kterým jsou zašifrovány citlivé informace v konfigurační databázi (právě hesla všech managed accounts a privátní klíče SharePoint vnitřní certifikační autority). Pokud passphrase neznáte, ještě nezoufejte. Na libovolném jiném SharePoint serveru ze stejného statku, který je funkční, stačí použít Set-SPPassphrase. Říkám na jiném, na nějakém, který funguje. Tím že ji změníte, se databáze přešifruje na novou passphrase, které už znáte.
- Až ji nastavíte přes ten jiný funkční server, musíte tu passphrase nastavit ještě do registrů vašeho poškozeného serveru. To uděláte pomocí Set-SPPassphrase -LocalServerOnly na tom poškozeném serveru. Tím se nemění heslo v databázi, jenom ho lokálně uložíte do registrů poškozeného serveru.
- V tuto chvíli jste tedy ve stavu, kdy SharePoint Timer Service alespoň startuje a jeho lokální passphrase je v pořádku.
- Pokud máte takto poškozených více serverů, zopakujte dosavadní postup na všech.
- Následuje klíčová akce tohoto článku. Vynutit opravu všech použitých managed account na všech službách a apppoolech. To udělejte zase raději z nějakého jiného jedoucího serveru. Pomocí Repair- SPManagedAccountDeployment. Prostě to spustíte a všechny servery na statku si znovu stáhnou z konfigurační databáze všechny managed accounty a znovu je nastaví všude, kde to jde.
A mělo by to být hotovo. |