Програма Portqry.exe повідомляє про стан порту TCP / IP в такий спосіб.
- Listening - Який-небудь процес прослуховує обраний порт на обраному комп'ютері. Програма Portqry.exe отримала відповідь від порту.
- Not Listening - Обраний порт зазначеного комп'ютера прослуховується жодним процесом. Програма Portqry.exe отримала повідомлення протоколу ICMP "Destination Unreachable - Port Unreachable" від перевіряється UDP-порта. Якщо ж перевіряється TCP-порт, програма отримала пакет підтвердження TCP з встановленим прапором Reset.
- Filtered - Перевіряється порт на обраному комп'ютері фільтрується. Програма Portqry.exe не отримала відповіді від цього порту. Тому невідомо, чи є на ньому прослуховує процес. За замовчуванням TCP-порт опитується три рази, а UDP-порт - один раз, після чого програма повідомляє, що порт фільтрується.
Засіб Portqry.exe може опитувати один порт, заданий список портів або послідовний діапазон портів.
Після цього потрібно додати функціонал службам інтернету (World Wide Web Services), для чого позначте чекбокси наступних компонент розробки додатків: ASP.NET, ISAPI Extensions і ISAPI Filters.
Наступним кроком йде настройка основних функцій HTTP (Common HTTP Features), де потрібно щоб були помічені всі чекбокси: Default Document, Directory Browsing, HTTP Errors, HTTP Redirection і Static Content.
Наступним кроком є налагодження функцій безпеки, де потрібно позначити чекбокс для Windows Authentication.
Ви можете вибрати будь-яку із запропонованих у вікні (Report Server Installation Options) опцій установки, задану за замовчуванням конфігурацію або відмовитися від настройки служби звітності на етапі установки компонент.
Після успішної установки компонент Report Server потрібно їх відразу оновити до останнього SP і, якщо такі є, встановити останній після SP кумулятивний пакет латок. У нашому випадку, це був SP2 і кумулятивний пакет зі статті KB936252.
Після установки всіх доступних оновлень, необхідно внести корективи в налаштування за замовчуванням IIS7. Для початку може знадобитися перезапустити службу веб-публікацій, що легко зробити в командному рядку, виконавши там команду IISRESET. Якщо перезапуск служб інтернету пройде успішно, Ви отримаєте такі повідомлення:
Наступним кроком є налагодження Report Server, яка документально підтверджена в BOL і виконується засобами оснащення: "Налаштування служб Reporting Services" (RSConfigTool.exe). Важливо, щоб Reporting Services працював як успадковане з точки зору IIS 7.0 додаток, тобто прикладної пул для віртуального каталогу Report Server повинен бути класичний: Classic .NET AppPool.
В довершення всього, щоб веб-вузол звітів і їх налаштування був доступний з локального комп'ютера, потрібно включити його в надійні вузли.
Чи не вперше зустрічаюся з тим, що настройка делегування для пов'язаних серверів (так в російській BOL прийнято називати Linked Server) викликає труднощі, які не так легко розв'язати, як це здається на перший погляд. Сама настройка описана в статті Налаштування пов'язаних серверів для делегування. там все виглядає просто і зрозуміло ... Однак, дуже часто замість очікуваного результату, повертається повідомлення про помилку:
Повідомлення 18456, рівень 14, стан 1, рядок 1
Login failed for user 'NT AUTHORITY \ ANONYMOUS LOGON'.
Невеликі дослідження шляхом пошуку в інтернет легко призводять до шуканим матеріалами по вирішенню цієї проблеми, які настільки докладні, що відлякують дуже багатьох ...
Насправді не потрібно лякатися, все вирішується дуже просто. Основною проблемою, про яку як правило забувають, є реєстрація т.зв. Service Principal Name (SPN) в Active Directory (AD). Справа в тому, що в залежності від цих параметрів можуть використовуватися різні схеми аутентифікації, причому, користувачі про це навіть не будуть здогадуватися. Однак, з двох можливих схем, для успішного делегування підходить тільки Kerberos, а NTLM зможе забезпечити правильне делегування тільки при запуску клієнтської програми безпосередньо на тому сервері, де налаштовується пов'язаний сервер. Нас же цікавить така схема аутентифікації, яка зображена на малюнку нижче і яка має на увазі використання базового делегування Kerberos.
Формат виклику утиліти такої: setspn [switches data] computername
Де "computername" має бути дозволеним іменем сервера або в форматі домен \ ім'я
У статті Troubleshooting Kerberos Delegation дуже докладно описані умови, при яких делегування можливо і представлені графічні схеми, що полегшують розуміння всіх необхідних вимог. Ось схема для нашого випадку:
З цієї схеми видно, що SPN потрібно зареєструвати для обох серверів.
Отже, давайте тепер по кроках повторимо все те, що необхідно зробити, для того, щоб делегування працювало так, як того вимагає умова нашого завдання.
Переконайтеся, що клієнт і обидва сервера підтримують протоколи TCP і / або іменовані канали. Крім того, всі вони повинні входити в один і той же домен, а ім'я входу користувача домену (для якого ми будемо налаштовувати делегування) має бути заведено логіном на обидва сервера, будемо їх називати SQLSERVER1 (на малюнках це Front-end або Middle Tier) і SQLSERVER2 (Back-end). Крім того, ця обліковий запис і ті записи, від імені яких запускаються служби СУБД на обох серверах, не повинні бути позначені, як "Account is sensitive and can not be delegated".
Як це показано в статті Налаштування пов'язаних серверів для делегування, створимо Linked Server:
EXEC sp_addlinkedserver 'SQLSERVER2', N'SQL Server '
EXEC sp_addlinkedsrvlogin 'SQLSERVER2', 'true'
Для перевірки можна виконати наступний запит:
SELECT * FROM sys.servers where name = 'SQLSERVER2' - для сервера SELECT uses_self_credential as delegation FROM sys.linked_logins as L, sys.servers as S where S.server_id = L.server_id and S.name = N 'SQLSERVER2' - - для перевірки делегування = 1
Переконайтеся, що з клієнта Ви можете підключитися до обох серверів. Наприклад так:
osql -E -S SQLSERVER1
osql -E -S SQLSERVER2
Переконайтеся, що доменним облікових записів, від імені яких запускаються SQL Server-а на обох серверах, присвоєні SPN. Присвоєння показано нижче, на прикладі SQLSERVER1:
C: \ Program Files \ Support Tools> setspn -A MSSQLSvc / SQLSERVER1.ІМЯДОМЕНА.ru: тисячі чотиреста тридцять три ІМЯВХОДАСЛУЖБИСУБД
У разі успішного результату видаються такі повідомлення:
Після цього варто перевірити, що аутентифікація KERBEROS, а транспорт TCP. Виконайте наступний запит, замінивши змінну на відповідний ідентифікатор:
select net_transport, auth_scheme from sys.dm_exec_connections where session_id = @@ spid
Переконайтеся, що при підключенні до SQLSERVER1 Ви можете отримати вибірку для запиту до пов'язаного сервера:
select * from SQLSERVER2.master.dbo.sysdatabases
Інші статті на цю тему:
Приклад листа, отриманого сьогодні мною у відповідь на замовлення CU # 3 для платформи х86 (лист прийшов через 3 години після заповнення форми):
The hot fix for your issue has been packaged and placed on an HTTP site for you to download.
WARNING: This fix is not publicly available through the Microsoft website as it has not gone through full Microsoft regression testing. If you would like confirmation that this fix is designed to address your specific problem, or if you would like to confirm whether there are any special compatibility or installation issues associated with this fix, you are encouraged to speak to a Support Professional in Product Support Services .
The package is password protected so be sure to enter the appropriate password for each package. To ensure the right password is provided cut and paste the password from this mail.
NOTE: Passwords expire every 7 days so download the package within that period to insure you can extract the files. If you receive two passwords it means you are receiving the fix during a password change cycle. Use the second password if you download after the indicated password change date.
NOTE: Be sure to include all text between '(' and ')' when navigating to this hot fix location!
Після того, як BOL став оновлюватися через Microsoft Update. це питання, напевно, буде хвилювати багатьох 🙂
Найпростіше, це заглянути в оснащення установки і видалення програм, яка присутня в списку панелі управління. У ній можна побачити подібну картину:
Останні випуски BOL забезпечені позначкою в дужках, коли вийшла встановлена версія. Будемо сподіватися, що так воно і буде надалі. Однак, не завжди є можливість отримати доступ до зображеної оснащенні. У таких випадках, може допомогти знання того, в яких ключах системного реєстру зберігаються ці значення. Те, що ми спостерігаємо в оснащенні, береться з гілки системного реєстру:
/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...
Чи не вперше стикаюся з тим, що виникає необхідність дізнатися, з яким ключем був встановлений сервер. Явного способу в документації і в інтернет поки знайти не вдалося, тому пропоную вам свій метод, який не претендує на якесь "супер-знання" і застосуємо зовсім не у всіх випадках ... Суть методу в тому, що інформація про використаний ключі зберігатися в логах установки . Зокрема, мені вдалося знайти ключ (добре, що я свідомо точно знав - який) у файлі: SQLSetup0001_хххххххххх_Tools.log (де букви "х" замінюють ім'я сервера) У цьому файлі Залогуватися всі внесені до реєстру зміни, зокрема, було видно , що в гілку реєстру:
Були додані параметри, в числі яких:
Розташовується цей файл за умовчанням в папці:
C: \ Program Files \ Microsoft SQL Server \ 90 \ Setup Bootstrap \ LOG \ Files