Błąd 0x800706BA — Serwer RPC jest niedostępny

Błąd 0x800706BA — Serwer RPC jest niedostępny: Kompletny poradnik rozwiązywania problemów

Błąd 0x800706BA najczęściej pojawia się podczas próby aktywacji systemu przez KMS, gdy komputer nie może nawiązać poprawnej komunikacji z usługą zdalną. W praktyce oznacza to problem z połączeniem sieciowym, usługą RPC, konfiguracją DNS albo dostępnością hosta aktywacji. Jeśli próbujesz wykonać aktywację Windows, a wpisany klucz produktu jest poprawny, sam kod 0x800706BA zwykle nie wskazuje na zły klucz, lecz na przerwaną komunikację pomiędzy klientem a serwerem aktywacji.

W 2026 roku, wraz z upowszechnieniem Windows 11 24H2 i nadchodzącym 25H2, mechanizmy aktywacji wolumenowej pozostają w centrum zarządzania flotą — szczególnie w polskich firmach przygotowujących się do migracji na Exchange Server SE i wdrażających integrację z KSeF. Poniższy przewodnik obejmuje wszystkie znane przyczyny błędu, kompletny proces diagnostyczny oraz sprawdzone metody naprawy, uwzględniając specyfikę zarówno małych biur (5–25 stanowisk), jak i średnich przedsiębiorstw (100–500 endpointów).

Jeżeli aktywujesz edycję Pro lub chcesz porównać dostępne ścieżki aktywacji, zobacz także: Windows 11 Professional — aktywacja.

Co oznacza błąd 0x800706BA

Kod 0x800706BA odpowiada komunikatowi: „Serwer RPC jest niedostępny”. RPC, czyli Remote Procedure Call, to mechanizm komunikacji wykorzystywany przez usługi systemowe i narzędzia aktywacyjne. Gdy system nie może połączyć się z serwerem KMS, nie rozwiązuje nazwy hosta albo ruch jest blokowany przez zaporę, aktywacja kończy się właśnie tym błędem.

W architekturze Windows 11 24H2 usługa RpcSs (Remote Procedure Call) odpowiada za komunikację między procesami lokalnymi i zdalnymi, w tym za wymianę danych między klientem Software Protection Platform a hostem KMS. Gdy którykolwiek element tego łańcucha zawiedzie — od resolwera DNS, przez stos TCP/IP, po polityki Windows Defender Firewall z regułami wdrażanymi przez Intune — system zgłasza właśnie 0x800706BA.

Ten problem występuje szczególnie często w środowiskach firmowych, gdzie wykorzystywana jest aktywacja zbiorcza oparta o KMS lub MAK, ale może pojawić się również po zmianach w sieci, migracji serwera, aktualizacji polityk bezpieczeństwa, wdrożeniu Microsoft 365 Copilot z nowymi regułami endpointowymi, czy wyłączeniu wymaganych usług Windows.

Główne przyczyny błędu w środowiskach Windows 11 i Windows Server 2025

Współczesne środowiska — szczególnie te korzystające z Windows 11 24H2, Windows Server 2025 oraz Exchange Server SE — wprowadzają dodatkowe warstwy, które mogą generować błąd 0x800706BA:

• Zablokowany port TCP 1688 na serwerze KMS lub po stronie klienta — najczęściej przez Windows Defender Firewall, reguły GPO lub zaporę sprzętową
• Nieprawidłowy rekord DNS SRV — wskazujący na nieistniejący host lub serwer, który został już wycofany z eksploatacji
• Niedostępny host KMS — wyłączony fizycznie, w trakcie migracji na nową wersję Windows Server lub zastąpiony przez ADBA (Active Directory-Based Activation)
• Zatrzymane usługi RpcSs, sppsvc lub LicenseManager — często po nieudanej aktualizacji zbiorczej (CU) lub konflikcie z oprogramowaniem antywirusowym
• Niezsynchronizowany czas — różnica większa niż 5 minut między klientem a kontrolerem domeny blokuje uwierzytelnianie Kerberos, a w konsekwencji RPC
• Nieprawidłowy klucz GVLK — użycie klucza KMS dla Windows 11 Enterprise na edycji Pro lub odwrotnie
• Konflikt metod aktywacji — system wcześniej aktywowany MAK, a następnie przełączany na KMS bez pełnego resetu (slmgr /ckms)
• Restrykcyjne reguły EDR/XDR — np. Microsoft Defender for Endpoint lub rozwiązania trzecie blokujące ruch RPC między strefami sieciowymi

Różnice między KMS, MAK i ADBA

W polskich realiach mała firma księgowa (15 stanowisk) najczęściej skorzysta z licencji MAK — aktywuje każdy komputer indywidualnie i uniknie problemów z RPC. Natomiast średnie przedsiębiorstwo produkcyjne (200 stanowisk, własny AD, serwer Windows Server 2025) wybierze KMS lub ADBA, co zapewnia automatyczną aktywację bez ręcznej interwencji na każdym endpointcie.

Diagnostyka krok po kroku

Zanim przejdziesz do naprawy, wykonaj systematyczną diagnostykę. Poniższa sekwencja pozwala precyzyjnie zlokalizować źródło problemu bez przypadkowego nadpisywania konfiguracji.

Krok 1: Weryfikacja rekordu DNS SRV

nslookup -type=srv _vlmcs._tcp

Jeśli polecenie nie zwraca żadnego rekordu, twoja domena nie ma opublikowanego wpisu SRV dla KMS. To pierwszy kandydat na przyczynę błędu.

Krok 2: Test łączności sieciowej z hostem KMS

Znając nazwę hosta z kroku 1, sprawdź podstawową osiągalność i otwartość portu:

Test-NetConnection nazwa_hosta_kms -Port 1688

Jeśli port 1688 jest zamknięty (TcpTestSucceeded: False), problem leży w firewallu, VLAN-ie lub serwerze KMS.

Krok 3: Sprawdzenie stanu usług krytycznych

Get-Service -Name RpcSs, sppsvc, LicenseManager | Format-Table Name, Status, StartType

Wszystkie trzy usługi muszą mieć status Running. RpcSs i sppsvc powinny mieć start typu Automatic.

Krok 4: Odczytanie szczegółów obecnej licencji

slmgr /dlv

Zwróć uwagę na pola: Description (np. Windows(R) Operating System, VOLUME_KMS_2019 channel), License Status oraz Remaining Windows rearm count. Jeśli Description zawiera KMS, a ty używasz klucza MAK (lub odwrotnie) — masz niezgodność.

Krok 5: Identyfikacja kanału aktywacji

Ustal, czy w twoim środowisku obowiązuje KMS, MAK, czy ADBA:

slmgr /dli

Skrócona informacja licencyjna pokaże nazwę kanału (np. VOLUME_KMSCLIENT) i pomoże potwierdzić, że klient jest skonfigurowany zgodnie z intencją administratora.

Krok 6: Sprawdzenie synchronizacji czasu

w32tm /query /status

Odchylenie większe niż 300 sekund między klientem a źródłem czasu domeny uniemożliwia poprawne uwierzytelnienie Kerberos, co kaskadowo zrywa komunikację RPC.

5 metod rozwiązania

Metoda 1: Sprawdź łączność z hostem KMS i odblokuj porty

Najpierw potwierdź, czy klient w ogóle widzi serwer aktywacji. W CMD lub PowerShell uruchomionym jako administrator:

nslookup -type=srv _vlmcs._tcp
ping NAZWA_HOSTA_KMS
Test-NetConnection NAZWA_HOSTA_KMS -Port 1688

Jeśli test portu kończy się niepowodzeniem, sprawdź po kolei:

• Firewall Windows na kliencie i serwerze: upewnij się, że reguła Key Management Service (TCP-In) jest włączona
• Zapora sprzętowa / UTM: odblokuj ruch TCP 1688 między segmentem klienckim a segmentem serwera
• VPN: jeśli klienci łączą się przez VPN, upewnij się, że ruch do portu 1688 nie jest tunelowany z pominięciem serwera KMS

Metoda 2: Ustaw host KMS ręcznie i ponów aktywację

Jeżeli rekord DNS jest błędny lub nie istnieje, możesz tymczasowo wskazać host ręcznie:

slmgr /skms nazwa_lub_ip_serwera_kms:1688
slmgr /ato
slmgr /dlv

Polecenie slmgr /skms nadpisuje automatyczne wykrywanie serwera. To dobra metoda testowa, gdy chcesz szybko sprawdzić, czy błąd wynika z DNS. Pamiętaj, że ręczne ustawienie jest trwałe — aby wrócić do automatycznego wykrywania, wykonaj slmgr /ckms.

Metoda 3: Zweryfikuj klucz produktu i kanał aktywacji

W części przypadków system jest skonfigurowany pod niewłaściwy typ licencji. Komputer przeznaczony do aktywacji KMS powinien mieć właściwy klucz GVLK, a środowisko MAK wymaga innej ścieżki. Wgraj poprawny klucz produktu, a następnie uruchom aktywację:

slmgr /ipk XXXXX-XXXXX-XXXXX-XXXXX-XXXXX
slmgr /ato
slmgr /xpr

Dla Windows 11 Enterprise (edycja 24H2) właściwym kluczem KMS jest publiczny GVLK — dostępny w dokumentacji Microsoft. Dla Windows 11 Professional użyj dedykowanego klucza produktu dostępnego w oficjalnej dystrybucji.

Jeżeli po zmianie klucza pojawi się inny kod, sprawdź również poradniki: błąd 0xC004C003 oraz błąd 0xC004F050.

Metoda 4: Sprawdź i uruchom wymagane usługi Windows

Aktywacja nie powiedzie się, jeśli usługi odpowiedzialne za licencjonowanie lub zdalne wywołania są zatrzymane. Sprawdź ich stan i uruchom:

Get-Service RpcSs, sppsvc, LicenseManager | Start-Service
Set-Service -Name sppsvc -StartupType Automatic

Po uruchomieniu usług ponów próbę:

slmgr /ato

Metoda 5: Oczyść konfigurację i odśwież status licencji

Gdy system długo pracował z nieaktualnym wpisem KMS, pomocne bywa wyczyszczenie konfiguracji i ustawienie jej od nowa:

slmgr /ckms
slmgr /cpky
slmgr /ipk XXXXX-XXXXX-XXXXX-XXXXX-XXXXX
slmgr /skms nazwa_lub_ip_serwera_kms:1688
slmgr /ato
slmgr /dlv

Ta metoda jest przydatna po migracji serwera KMS na Windows Server 2025, zmianie DNS, przejściu między KMS i MAK, a także po migracji z Exchange Server 2019 na Exchange Server SE, gdy reorganizujesz infrastrukturę domenową.

Tabela kodów błędów pokrewnych — szybka diagnostyka różnicowa

Jeśli po próbie aktywacji pojawia się inny kod niż 0x800706BA, poniższa tabela pomoże szybko zidentyfikować właściwy kierunek działania:

Prewencja — jak uniknąć błędu 0x800706BA w przyszłości

Aby ograniczyć ryzyko ponownego wystąpienia błędu 0x800706BA, warto wdrożyć kilka prostych zasad:

• Utrzymuj poprawne rekordy DNS SRV dla hosta KMS — po każdej migracji serwera weryfikuj wpis poleceniem nslookup -type=srv _vlmcs._tcp
• Monitoruj dostępność portu TCP 1688 — narzędzia takie jak PRTG, Zabbix czy prosty skrypt PowerShell w harmonogramie zadań pozwalają wykryć awarię, zanim użytkownicy zgłoszą problem
• Nie mieszaj konfiguracji KMS i MAK na tych samych stacjach bez pełnego resetu ustawień (slmgr /ckms, slmgr /cpky)
• Pilnuj synchronizacji daty i godziny w domenie — kontroler domeny powinien być autorytatywnym źródłem czasu (NTP), a klienci synchronizować się z hierarchią domenową
• Dokumentuj, jaki klucz produktu został użyty dla danej edycji systemu — szczególnie gdy zarządzasz mieszaną flotą Windows 10, Windows 11 24H2 i Windows Server 2025
• Po wdrożeniu Exchange Server SE i towarzyszących zmianach w architekturze AD, ponownie przetestuj aktywację na reprezentatywnej grupie klientów
• Jeśli korzystasz z KSeF i związanego z nim ruchu sieciowego przez bramki UTM, upewnij się, że nowe reguły firewall nie blokują portu 1688 — integracje fiskalne często wprowadzają restrykcyjne polityki segmentacji sieci

Przykład z życia: firma produkcyjna (230 stanowisk, Windows 11 Enterprise, domena AD)

Firma wdrożyła Windows 11 24H2 na 230 laptopach działowych. Klucze GVLK zostały wgrane podczas deploymentu z SCCM. Po przeniesieniu serwera KMS na nową maszynę z Windows Server 2025 administrator zapomniał dodać rekordu SRV w DNS. Efekt: po 180 dniach wszystkie stacje zaczęły wyrzucać błąd 0x800706BA. Rozwiązanie: dodanie poprawnego rekordu SRV i ponowne uruchomienie usługi sppsvc na klientach przez GPO — czas naprawy: 45 minut dla całej floty.

Scenariusze naprawcze — wybierz swoją ścieżkę

W zależności od wielkości środowiska i posiadanej infrastruktury, zastosuj jedno z poniższych podejść.

Środowisko bez domeny (WORKGROUP, małe biuro 5–25 PC)

W tym scenariuszu nie masz lokalnego serwera KMS. Aktywujesz każde stanowisko kluczem MAK. Jeśli trafiłeś na 0x800706BA, to najprawdopodobniej przez pomyłkę użyto klucza GVLK (przeznaczonego dla KMS) zamiast klucza MAK. Rozwiązanie: slmgr /ckms, slmgr /ipk KLUCZ_MAK, slmgr /ato. Jeżeli potrzebujesz nowego klucza do Windows 11 Professional, sprawdź oficjalne źródła dystrybucji kluczy produktowych.

Środowisko domenowe z serwerem Windows Server 2022/2025 i KMS

Standardowy scenariusz dla firm 50+. Diagnostyka: sprawdź DNS SRV, test portu 1688, stan usług. W razie problemu użyj Metody 5 (czyszczenie konfiguracji). Jeśli to nie pomoże, rozważ przejście na ADBA — eliminuje zależność od osobnego hosta KMS i portu 1688, a aktywacja odbywa się przez Active Directory.

Środowisko z Microsoft 365 Copilot i Intune

Jeśli zarządzasz flotą przez Intune, błąd 0x800706BA może wynikać z konfliktu polityk. Sprawdź w portalu Intune, czy profile konfiguracji urządzeń (Device Configuration Profiles) nie blokują portu 1688 lub nie wyłączają usług sppsvc / RpcSs. W razie potrzeby utwórz politykę naprawczą PowerShell, która wykona sekwencję z Metody 5 i wdróż ją na grupę testową przed objęciem całej floty.

Częste pytania

Dlaczego błąd 0x800706BA pojawia się nagle po tygodniach poprawnego działania?

Najczęstszą przyczyną jest upływ 180-dniowego okresu aktywacji KMS — system próbuje odnowić licencję i po raz pierwszy od pół roku kontaktuje się z serwerem, który w międzyczasie zmienił adres, został wyłączony lub stracił wpis DNS. Drugim typowym powodem jest aktualizacja zbiorcza Windows 11, która resetuje konfigurację firewalla.

Czy błąd 0x800706BA może być spowodowany przez wadliwy klucz produktu?

Nie bezpośrednio. Wadliwy klucz zwróci kod 0xC004C003 lub 0xC004F050. Kod 0x800706BA oznacza, że klient w ogóle nie dotarł do serwera aktywacji, więc klucz nie został jeszcze zweryfikowany. Dopiero po naprawieniu komunikacji RPC system sprawdzi poprawność klucza.

Jak sprawdzić, czy mój klucz to GVLK (KMS), czy MAK?

Na istniejącym systemie użyj slmgr /dli. Jeśli w polu Description widnieje VOLUME_KMSCLIENT, masz klucz KMS. Sam klucz GVLK jest publiczny — dla Windows 11 Enterprise 24H2 to np. NPPR9-FWDCX-D2C8J-H872K-2YT43 (dokładny klucz zależy od edycji i wersji — zawsze weryfikuj w oficjalnej dokumentacji Microsoft).

Czy mogę aktywować Windows 11 przez KMS, jeśli korzystam z Exchange Server SE w tej samej domenie?

Tak, usługi te są niezależne. Exchange Server SE wymaga własnej licencji i nie wpływa na mechanizm aktywacji systemu operacyjnego. Problem może pojawić się tylko, gdy migracja na Exchange SE wiąże się z reorganizacją domeny i zmianą rekordów DNS — wtedy upewnij się, że wpis _vlmcs._tcp został przeniesiony.

Co zrobić, gdy nie mam dostępu do serwera KMS, a błąd 0x800706BA blokuje pracę?

Do czasu naprawy możesz tymczasowo aktywować system kluczem MAK (jeśli posiadasz go w umowie Volume Licensing). Alternatywnie, jeśli twoja firma ma mniej niż 25 stanowisk Windows, rozważ całkowitą rezygnację z KMS na rzecz MAK lub ADBA — unikniesz problemów z RPC w przyszłości.

Dlaczego slmgr /skms działa, ale aktywacja ponownie się psuje po restarcie?

Ręczne ustawienie slmgr /skms jest trwałe — przeżywa restart. Jeśli mimo to po restarcie pojawia się błąd, sprawdź, czy GPO nie nadpisuje tego ustawienia (polityka Computer Configuration → Administrative Templates → Windows Components → Software Protection Platform) albo czy skrypt startowy nie przywraca starej konfiguracji.

Czy błąd 0x800706BA występuje również przy aktywacji Office 2024?

Tak. Office 2024 Professional Plus w kanale Volume License również korzysta z KMS i może zwrócić ten sam kod błędu, jeśli host KMS jest nieosiągalny. Diagnostyka jest identyczna — nslookup -type=srv _vlmcs._tcp i test portu 1688. Office 2024 dołączony do subskrypcji M365 Copilot korzysta natomiast z aktywacji opartej na użytkowniku (User-Based Licensing), więc błąd KMS go nie dotyczy.

Czy polski KSeF ma wpływ na błąd 0x800706BA?

Pośrednio tak. Wdrożenie KSeF (Krajowego Systemu e-Faktur) często wiąże się z nowymi regułami firewalla i segmentacją sieci w firmie — ruch do systemów fiskalnych jest priorytetyzowany, a pozostały ruch (w tym port 1688) może zostać przypadkowo zablokowany. Po każdej zmianie reguł UTM/NGFW warto ponownie zweryfikować komunikację KMS.

Gdzie kupić klucz aktywacyjny, gdy mój okazał się niekompatybilny?

Jeśli potrzebujesz nowego klucza do Windows 11 Professional, Office 2024 lub innego produktu Microsoft, legalne klucze w cenach netto z polską Fakturą VAT 23% znajdziesz w autoryzowanych źródłach dystrybucji. Wybierając klucz, zwróć uwagę na zgodność z edycją systemu i kanałem licencyjnym (Retail vs. Volume).

Czy slmgr /ipk z kluczem GVLK jest legalne?

Tak, o ile twoja organizacja posiada aktywną umowę Volume Licensing z Microsoft. Klucze GVLK są publicznie udostępniane właśnie po to, by klienci zbiorczy mogli je wgrać przed aktywacją KMS. Samo posiadanie klucza GVLK bez umowy nie daje prawa do korzystania z oprogramowania — licencję potwierdza serwer KMS, nie sam klucz.