Programul Portqry.exe raportează starea portului TCP / IP după cum urmează.
- Ascultarea - Orice proces ascultă pe portul selectat de pe calculatorul selectat. Portqry.exe a primit un răspuns de la port.
- Nu ascultați - Portul selectat al computerului specificat nu este ascultat de nici un proces. Portqry.exe a primit mesajul ICMP "Destination Unreachable - Port Unreachable" de la portul UDP scanat. Dacă este bifat portul TCP, programul a primit un pachet de confirmare TCP cu setul de parametri Reset.
- Filtrat - Portul testat de pe calculatorul selectat este filtrat. Portqry.exe nu a primit un răspuns de la acest port. Prin urmare, nu se știe dacă există un proces de audiere pe aceasta. În mod implicit, portul TCP este interogat de trei ori, iar portul UDP este interogat o dată, după care programul raportează că portul este filtrat.
Instrumentul Portqry.exe poate sondona un port, o listă de port specificată sau un interval de port serial.
Apoi adăugați funcționalitatea la serviciile World Wide Web prin marcarea casetelor de selectare ale următoarelor componente de dezvoltare a aplicațiilor: ASP.NET, ISAPI Extensions și ISAPI Filters.
Următorul pas se configurează funcțiile de bază HTTP (HTTP Caracteristici comune), în cazul în care este necesar ca toate casetele de selectare sunt marcate: Document implicit, director de navigare, erori HTTP, redirectionarea HTTP și conținut static.
Următorul pas este să configurați funcțiile de securitate, unde trebuie să bifați caseta pentru Windows Authentication.
Puteți selecta oricare dintre opțiunile oferite în fereastra Opțiuni de instalare a serverului de rapoarte, configurația implicită sau refuzați configurarea serviciului de raportare în timpul fazei de instalare a componentelor.
După instalarea cu succes a componentei Report Server, trebuie să le actualizați imediat la cel mai recent SP și, dacă este cazul, să instalați cel mai recent pachet de pachete SP cumulative. În cazul nostru, a fost SP2 și pachetul cumulativ de la KB936252.
După instalarea tuturor actualizărilor disponibile, trebuie să efectuați ajustări la setările implicite ale IIS7. Pentru a începe, este posibil să trebuiască să reporniți serviciul Web Publishing, ceea ce este ușor de făcut în linia de comandă prin rularea comenzii IISRESET. Dacă repornirea serviciilor de Internet are succes, veți primi următoarele mesaje:
Următorul pas este de a configura serverul de rapoarte, care este documentat în BOL și se realizează prin intermediul într-o clipă: „Configurarea Reporting Services“ (RSConfigTool.exe). Este important ca Serviciile de Raportare să funcționeze ca o aplicație moștenită din punctul de vedere al IIS 7.0, adică Piscina aplicației pentru directorul virtual al serverului de rapoarte trebuie să fie clasică: clasic .NET AppPool.
Pentru a face totul off, site-ul de raport și setările pot fi accesate de pe computerul local, trebuie să-l includeți în site-urile de încredere.
Nu pentru prima dată când mă întâlnesc cu faptul că înființarea unei delegații pentru serverele conectate (așa cum se numește BOL denumită în mod obișnuit Server legat) cauzează dificultăți care nu sunt la fel de ușor de rezolvat cum pare la prima vedere. Configurarea însăși este descrisă în Configurarea serverelor conectate pentru delegare. totul pare simplu și ușor de înțeles ... Cu toate acestea, foarte des, în loc de rezultatul așteptat, se întoarce un mesaj de eroare:
Mesajul 18456, nivelul 14, starea 1, linia 1
Conectarea nu a reușit pentru utilizatorul 'NT AUTHORITY \ LOGON ANONIMO'.
Cercetările mici prin căutarea pe Internet conduc cu ușurință la materialele dorite pentru a rezolva această problemă, care sunt atât de detaliate încât ele sperie foarte multe ...
De fapt, nu vă speriați, totul este foarte simplu. Principala problemă, care este de obicei uitată, este înregistrarea așa-numitului. Numele principal de serviciu (SPN) în Active Directory (AD). Problema este că, în funcție de aceste setări, pot fi utilizate diferite scheme de autentificare, iar utilizatorii nu vor ghici despre asta. Cu toate acestea, două scheme posibile pentru delegare de succes este adecvat numai Kerberos și NTLM va fi în măsură să asigure delegarea adecvată numai în cazul în care aplicația client se execută direct pe serverul pe care este configurat serverul conectat. De asemenea, suntem interesați de o astfel de schemă de autentificare, care este descrisă în figura de mai jos și care implică utilizarea delegării de bază Kerberos.
Formatul apelului de utilitate este: setspn [switches data] numele computernamei
În cazul în care "nume_computerizat" trebuie să fie un nume de server valid sau în formatul \ nume de domeniu
Depanarea articolului Kerberos descrie în detaliu condițiile în care este posibilă delegarea și sunt furnizate scheme grafice pentru a facilita înțelegerea tuturor cerințelor necesare. Iată schema pentru cazul nostru:
Din această diagramă este clar că SPN trebuie să fie înregistrat pentru ambele servere.
Deci, acum să repetăm pașii pe care trebuie să-i facem pentru a ne asigura că delegația funcționează conform cerințelor condiției noastre.
Asigurați-vă că clientul și ambele servere acceptă conducte TCP și / sau numite. În plus, acestea trebuie să fie în același domeniu, și un nume de utilizator pentru utilizator de domeniu (pentru care vom configura delegația) ar trebui să fie instituit de conectare la ambele servere, noi le numim SQLServer1 (în figuri acest front-end sau de nivel mediu) și SQLSERVER2 (Back-end). În plus, acest cont și înregistrările în numele cărora se difuzează serviciile DBMS pe ambele servere nu ar trebui marcate ca "Contul este sensibil și nu poate fi delegat".
După cum se arată în Configurarea serverelor conectate pentru delegare, creați un server conectat:
EXEC sp_addlinkedserver 'SQLSERVER2', server N'SQL '
EXEC sp_addlinkedsrvlogin 'SQLSERVER2', 'adevărat'
Pentru verificare, puteți executa următoarea interogare:
SELECT * FROM sys.servers în cazul în care numele = 'SQLSERVER2' - serverul SELECT uses_self_credential ca Delegație din sys.linked_logins ca L, sys.servers ca S în cazul în care S.server_id = L.server_id și S.name = N 'SQLSERVER2' - - pentru a verifica delegarea = 1
Asigurați-vă că vă puteți conecta la ambele servere de la client. De exemplu:
osql -E -S SQLSERVER1
osql -E -S SQLSERVER2
Asigurați-vă că conturile de domeniu pe care rulează SQL Server pe ambele servere sunt atribuite SPN. Cesiunea este prezentată mai jos, utilizând exemplul SQLSERVER1:
C: \ Program Files \ Support Tools> setspn -O MSSQLSvc / SQLSERVER1.IMYaDOMENA.ru: 1433 IMYAVHODASLUZHBYSUBD
Dacă rezultatul este reușit, sunt afișate următoarele mesaje:
După aceea, merită verificat faptul că autentificarea este KERBEROS și transportul TCP. Executați următoarea interogare prin înlocuirea variabilei cu identificatorul corespunzător:
selectați net_transport, auth_scheme din sys.dm_exec_connections unde session_id = @@ spid
Asigurați-vă că atunci când vă conectați la SQLSERVER1, puteți obține o selecție pentru o interogare către serverul conectat:
selectați * din SQLSERVER2.master.dbo.sysdatabases
Alte articole pe această temă:
Un exemplu de scrisoare primită astăzi ca răspuns la o comandă CU # 3 pentru platforma x86 (scrisoarea a venit la 3 ore după completarea formularului):
Remedierea fierbinte pentru problema dvs. a fost ambalată și plasată pe un site HTTP pe care îl puteți descărca.
AVERTISMENT: Această remediere nu este disponibilă public pe site-ul Microsoft. Dacă doriți să știți cum să remediați această problemă, trebuie să știți cum să remediați această problemă. .
Pachetul este protejat prin parolă. Pentru a vă asigura că este furnizată parola corectă.
NOTĂ: Parolele expiră la fiecare 7 zile, astfel încât să descărcați pachetul în acea perioadă pentru a vă asigura că puteți extrage fișierele. Dacă primiți două parole. Utilizați a doua parolă dacă descărcați după parola indicată.
NOTĂ: Asigurați-vă că includeți tot textul între '(' și ')' când navigați la această locație fixă!
După ce BOL a fost actualizat prin Microsoft Update. această întrebare, cu siguranță, va excita multe 🙂
Cel mai simplu lucru este să examinați modulul de instalare și dezinstalare care se află pe lista panoului de control. În el puteți vedea o imagine similară:
Ultimele date ale BOL sunt marcate cu paranteze atunci când versiunea instalată a ieșit. Să sperăm că așa va fi în viitor. Cu toate acestea, nu este întotdeauna posibilă accesarea snap-ului ilustrat. În astfel de cazuri, cunoașterea cheilor de registry la care sunt stocate valorile poate ajuta. Ceea ce vedem în snap este luat din ramura registrului de sistem:
/ 1: SQL / 2: 9.0000.7103.1552 / 3: 1,0 / 4: sqlgtst9 / 5: ms-help: //MS.SQLCC.v9/MS.SQLSVR.v9.ru/sqlgtst9/html/91ddee3a ...
Nu pentru prima dată când am dat peste faptul că devine necesar să aflăm cu ce cheie a fost instalat serverul. Un mod explicit în documentația și pe internet, atâta timp cât nu a fost posibil să se găsească, așa că vă sugerez o metodă care nu pretinde a fi un fel de „super-cunoaștere“ și se aplică nu în toate cazurile ... esența metodei este aceea de utilizare a informațiilor cheie stocate în jurnalele de instalare . În special, am fost în stare să găsească un indiciu (bine, evident, am știut - a) în fișierul: SQLSetup0001_hhhhhhhhhh_Tools.log (în cazul în care litera „x“ se înlocuiește cu numele serverului) Acest fișier jurnal toate făcute la modificările de registry de sistem, în special, a fost văzut , că în ramura de registru:
Au fost adăugate parametri, inclusiv:
Acest fișier implicit este localizat în folderul:
C: \ Program Files \ Microsoft SQL Server \ 90 \ Setup Bootstrap \ LOG \ Fișiere
Trimiteți-le prietenilor: