TS Gateway SSL Cerificate Issue

Після встановлення та конфігурації ролі TS Gateway проявилася неприємна особливість: встановлюємо валідний SSL сертифікат, але після оновлення консолі отримуємо повідомлення: "xx is not yet fully configured as a TS Gatewayserver...". В логах при цьому фіксуються події 15300 та 1530: "SSL certificate settings deleted for port %internalIP%:443, SSL certificate settings created by an admin process for port %internalIP:443". В процесі пошуку відповіді було знайдено наступний пост з ідентичною проблемою: http://www.eggheadcafe.com/software/aspnet/31830077/terminal-services-gateway.aspx.
В статті вказано, що така поведінка виникає, коли в налаштування біндінга IIS вказано конкретну IP- адресу, і необхідно замість неї встановити All Unassigned. Після цього необхідно перезавантажити Default Web Site і можна нормально конфігурувати сертифікат в налаштуваннях TS Gateway.

Add Group to Local Admins

Стандартна ситуація - необхідно програмними засобами додати деяку доменну або локальну групу до групи локальних адміністратрів машини. Приводжу простий код на c#, що виконує дану задачу:

using System;

using System.DirectoryServices;

using System.Collections;

namespace AddLocalAdmin

{

    class Program

    {

        public static void AddGroupToLocalAdmins(string GroupAdd)

        {

            bool IsPresent = false;

            DirectoryEntry grp = new DirectoryEntry("WinNT://" + Environment.MachineName + "/Administrators,group");

            object members = grp.Invoke("members", null);

            foreach (object groupMember in (IEnumerable)members)

            {

                DirectoryEntry member = new DirectoryEntry(groupMember);

                if (member.Name == GroupAdd) IsPresent = true;

            }

            if (!IsPresent) grp.Invoke("Add", "WinNT://" + Environment.MachineName + "/" + GroupAdd + ",group");

            else

            {

                Console.WriteLine("Already present");

                

            }

            grp.CommitChanges();

        }

        public static void Main(string[] args)

        {

            try

            {

                AddGroupToLocalAdmins(args[0]);

                Console.WriteLine("huj {0}", args[0]);

                Console.ReadLine();

            }

            catch (Exception ex)

            {

                Console.WriteLine(ex.Message + "\n" + ex.StackTrace + "\n" + ex.Source); 

                Console.ReadLine();

            }

        }

    }

}

Якщо замість локальної додаємо доменну групу, то в методі grp.Invoke замість парамтеру "WinNT://" + Environment.MachineName + "/" + GroupAdd + ",group" вказуємо "WinNT:///" + GroupAdd + ",group"

Можливо комусь цей код і стане в нагоді.

OCS 2007: ABS issues

Кожен адміністратор, після розгортання OCS 2007 стикається з багатьма проблемами, наприклад - синхронізація клієнтів з глобальною адресною книгою. В процесі її вирішення натрапив на досить непогану статтю, що описує типові проблеми ABS: http://ucnoevil.blogspot.com/2008/03/address-book-chaos.html. 

Також наведу іншу, досить лаконічну інструкцію з траблшутінгу даної служби:

 

Cannot synchronize address book information

Background. The OLC 2007 client says “Cannot synchronize address book information”

Cause: Misc. Related to IIS.

Look in the IIS logs to see which error code you are getting when the client
tries to download the address book

 

If you are seeing 403.1 - “Unauthorized access because the logon has failed”, try either:

1. Remove SSL. You’ll have to disable SSL in IIS and Change the OCS AB URL path in WMI.
2. OR, keep SSL enabled, but make sure that you can resolve the name (and successfully connect to) the CA’s CRL distribution point.

 

If you are seeing 403.14 - “Forbidden because the directory listing is denied”:

Enable directory browsing in IIS for the ABS application under the default web site;

 

If you are seeing Kerberos auth problems, you may need to add the SPN for IIS to the domain.

SetSpn -A HTTP/FQDN of IIS Server NetBios Name of IIS Server

 

Michael Folin
Systems Engineer
michael@folin.com

 

Проте, пройшовши всі кроки, описані в наведених статтях і не знайшовши вирішення, звернув увагу на правила публікації ISA 2006 - на закладці Authentication Delegation було встановлено значення No delegation, and clients can't authenticate directly. Це означає, що будь-який запис на авторизацію, надісланий клієнту ISA не передаватиме, саме тому в логах IIS і виникали помилки 401 2. Як тільки було встановлено значення No delegation, but clients may authenticate directly, проблему було вирішено. 

SCVMM 2008, знайомство

На днях зареєструвався на участь в тестуванні іспиту TS: System Center Virtual Machine Manager 2008, Configuring. Участь на період тестування безкоштована, проте за умов успішної здачі статус TS є цілком реальним. Ось деякі основні моменти, котрі необхідно врахувати при підготовці до іспиту(з сайту Microsoft):

Installing SCVMM

• Install SCVMM server components
• May include but is not limited to: Server prerequisites, database, Windows versions, enabling SAN migration, User Access Control (UAC) issues.
• Install administrator console
• May include but is not limited to: Administrator console prerequisites, platform support, firewall settings, Workgroup requirements vs. Domain requirements, custom ports, managed hosts from admin console, enable reporting for admin console.
• Install self-service portal
• May include but is not limited to: self-service portal prerequisites, IIS components, compatibility, custom ports, host headers.
• Install PRO tips
• May include but is not limited to: Ops manager, management packs, Admin consoles, security.

Administering SCVMM

• Configure user roles
• May include but is not limited to: delegate admin, setting permissions for specific host or host groups, using self-service portal to create test environment, add delegated administrator.
• Setup self service
• May include but is not limited to: enabling user or group for self service, setting custom ports for self service, establishing quota, Self-provisioning (templates).
• Maintain VMM library
• May include but is not limited to: adding a library, adding additional library shares or servers, moving files to library share, mapping ISOs, types of library files.
• Configure hosts
• May include but is not limited to: adding hosts, installing a local agent, adding VMware VC server, configuring a virtual network, creating filters in the console.
• Monitor jobs
• May include but is not limited to: verifying specific jobs, recovering from job failure, change tracking, job filtering.

Maintaining and Monitoring VMs

• Configure VM hardware
• May include but is not limited to: NIC configuration, configuring VM drive, configuring memory, configuring CPU.
• Manage virtual instance checkpoints and patches
• May include but is not limited to: Checkpoints, creating a checkpoint of a VM, deploying patches.
• Monitoring and reporting VMs
• May include but is not limited to: integrating Ops Manager, selecting potential virtualization targets, monitoring utilization.

Deploying and Migrating VMs

• Convert from physical or virtual platforms
• May include but is not limited to: P2V, V2V.
• Move VMs between hosts
• May include but is not limited to: migrating a SAN, migration options, intelligent placement.
• Deploy VMs
• May include but is not limited to: deploy VM from VHD, deploy VM from template, create template from existing VM, provisioning new machines and applications, intelligent placement.
• Deploy a High Availability VM
• May include but is not limited to: configuring host clustering, configuring guest clustering, configuring a VM for high availability, configuring library shares for high availability.

Термінальні граблі 2008

В цій замітці я приділю увагу тому, що чекає нас на шляху впровадження основних термінальних служб Windows 2008.

Навіщо нам це треба? Переваг досить багато, і найголовніші з них – можливість публікації окремих програм та доступу з будь-якої точки мережі без використання VPN.

Що для цього треба? Як мінімум –  Windows Server 2008та трохи часу.

Для початку визначаємось, які ролі має виконувати наш сервер. По-перше, це власне Terminal Server, TS Gateway для організації  доступу з Інтернет, а також TS WebAccess – це забезпечить можливість отримати доступ до опублікованих програм через веб-інтерфейс.

Встановити ролі можна за допомогою утиліти servermanagercmd.exe:

 

servermanagercmd –install TS-Terminal-Server

servermanagercmd –install TS-Gateway

servermanagercmd –install TS-Web-access

 

Після встановлення цих ролей та їх залежностей (веб –сервер, інструменти керування та ін) сервер необхідно перезавантажити.

От тут то нас і чекають граблі номер раз – навіть якщо ми маємо нормальні, дійсні сервери ліцензування термінальних серверів в нашій організації, нас буде повідомлено про те, що для роботи сервера на основі Windows 2008 версія ОС сервера ліцензування має бути не нижчою.

Розібравшись з ліцензуванням, або відклавши це питання на кращих часів (120 днів випробного терміну), переходимо до конфігурації кожної з ролей.

Почнемо зі шлюзу. Детально процедуру описано в статті http://technet.microsoft.com/en-us/library/cc754252.aspx . Перш за все, нам необхідно встановити на нього валідний сертифікат. Його ім’я має співпадати з тим іменем, що використовуватимуть користувачі для з’єднання зі шлюзом. Для цього ми маємо імпортувати його в сховище personal на сервері, а потім за допомогою консолі TS Gateway Manager у властивостях відповідного сервера, на вкладці SSL Certificate обрати його. Переходимо до контейнеру policies. Він містить контейнери, що зберігають CAP (Connections Authorization Policies) та RAP (Resource Authorization Policies). Перші визначають хто може під’єднуватися до шлюзу, а останні – встановлюють групи ресурсів, доступні для певних груп користувачів.

Переходимо до конфігурації RemoteApps. Всі операції достпуні через консоль TS RemoteApp Manager. Відкривши Terminal Server Setting маємо можливість задати повне ім’я термінального сервера, на якому встановлено програми, що публікуються, а на закладці Gateway Settings визначаємо, який шлюз використовувати для підєднання до термінального серверу, метод автентифікаці та можливість оминати шлюз для локальних адрес.  Щоб опублікувати певну програму, достатньо додати її в список RemoteApp Programs, розташований внизу консолі. Зробити ці програми доступними для користувачів ми можемо однім з кількох методів – створивши .rdp-файли і розповсюдивши їх на клієнтські машини, створивши пакети інсталяції .msi та встановивши їх користувачам за допомогою групових політик, або ж опублікувавши через WebAccess.

Конфігурація WebAccess полягає в тому, що ім’я цього сервера вноситься в локальну групу Web Access Computers на термінальному сервері, та обікового запису адміністратора в групу TS Web Access Administrators. Отримати доступ до сторінки з опублікованими програмами можна за адресою https://webacc/ts.

Якщо шлюз та сервер WebAccess розташовано всередині корпоративної мережі, то для зовнішніх користувачів їх можна опублікувати за допомогою MS ISA Server, розміщеного в периметрі. Створивши звичайне правило публікації веб-серверу згідно інструкції в статті http://technet.microsoft.com/en-us/library/cc731353.aspx. Специфічний момент полягає в тому, що якщо на одному зовнішньому інтерфейсі ISA вже опубліковано ssl сайт, то ми не можемо опублікувати інший на тому ж порту (досить логічно). Щоб вийти з цієї ситуації, ми просто назначаємо мережевому інтерфейсу альтернативну ip-адресу та направляємо дві різних web-listener на різні IP, і в цьому випадку для двох сайтів можна використовувати один і той же порт (в нашому випадку 443). Після того, як назначено додаткову адресу й написано правило, не полініться – перезавантажте ISA сервер. Свого часу недотримання цієї рекомендації коштувало мені кілько робочих днів та купи нервів. Це власне були граблі номер два.

Тепер шлюз термінальних серверів та WebAccess досяжні як з внутрішньої мережі, так і ззовні.  В результаті користувачі мають можливість отримати з будь-якої точки мережі доступ до своїх робочих місць та необхідних інструментів, а адміністратори можуть бути спокійнішими за безпеку середовища, оскільки більше немає потреби виставляти в зовнішню мережу RDP-порти або давати доступ по VPN рядовим користувачам. Виграють всі =).

Citrix Virtualization Conference 2008

Сьогодні, 9 вересня 2008 року в приміщенні Raddisson SAS hotel відбулася конференція, що мала на меті висвітлити бачення компанії Citrix з приводу такої актуальної теми, як віртуалізація. При цьому, йдеться не лише про віртуалізацію серверних платформ, а розглядається принципово нова парадигма, що в основі своїй містить ідею перетворення дата-центра на центр «доставки прикладних програм» кінцевому користувачеві.

Як зазначив у своїй вступній доповіді регіональний віце-президент компанії Citrix Karl-Heinz Warum: «Business Runs on Applications», тобто метою всієї ІТ-інфраструктури є надання можливості користувачам працювати з певними застосунками. І, повірте, не має цікавити на якій платформі розгорнуто конкретне рішення, як маршрутизуються пакети в мережі, яким чином встановлюється з’єднання з тим чи іншим сервером. Для кінцевого користувача важливим є те, що натиснувши на певний значок він отримає на десктопі знайомий інтерфейс.

Було зазначено, що однією з ключових проблем сучасного бізнесу є все більше віддалення користувача від прикладних програм, які поступово з персональних ПК витісняються на платформи корпоративних ЦОД, або ж повністю переселяються на простори Web. Така ситуація, з одного боку, відповідає загальним тенденціям до централізації обчислювальних потужностей, але з іншого боку також підвищує вимоги до обслуговування інфраструктури. Все більшої актуальності набувають питання максимальної утилізації ресурсів та ефективності керування системами.

Саме для подолання даної проблеми розроблено концепцію «Інфраструктури доставки прикладних програм». Вона передбачає такі засоби:

·         віртуалізація серверних платформ з метою кращої утилізації потужностей, збільшення стабільності та спрощення міграції серверів;

·         віртуалізація прикладних програм, що має на меті вирішення питання доставки їх кінцевому користувачу;

·         віртуалізація робочого середовища користувача, що радикальним чином спрощує обслуговування та сприяє підвищенню безпеки.

Реалізацією цих ідей є відповідно продукти XenSever, XenApp та XenDesktop. Зупинимося на кожному з них більш детально.

XenServer являє собою продукт для віртуалізації серверних платформ, що реалізує максимально прості та ефективні методи надання серверних ресурсів «на вимогу». Технології XenServer дозволяють оперативно перерозподіляти ресурси не тільки віртуальних але й фізичних серверів у відповідь на динамічні зміни потреб бізнесу. XenServer встановляється безпосередньо на апаратну платформу. Більш того - сучасні сервери HP вже мають попередньо встановлений XenServer, що розміщується на USB-драйві, а також набір інструментів для ефективного керування гостьовими ОС. В залежності від редакції XenServer може підтримувати різну кількість оперативної пам’яті та процесорних сокетів. За даними аналітичних агентств, на сьогодні вірутуалізовано порядку 9% загальної кількості серверів, тож потенціальний ринок для використання даного продукту є величезним.

XenApp – це система доставки Windows-застосунків, що реалізує технологію віртуалізації як на стороні сервера, так і на стороні клієнта. XenApp пропонує два методи доставки:

· традиційний термінальний режим, коли програма повністю виконується на сервері;

· «потоковий», коли програма у вигляді набору файлів завантажується з сервера на робочу станцію та виконується в ізольованому оточенні.

В обох випадках програми зберігаються на сервері, що забезпечує централізоване керування та знижує витрати на підтримку на 40%.

XenDesktop – це система, що дозволяє віртуалізувати клієнтські робочі місця та надавати доступ до них з будь-якої точки мережі. XenDesktop спрощує супроводження робочих місць користувачів та суттєво зменшує витрати на їх підтримку, а також дозволяє підвищити загальну безпеку системи. В редакції “platinum” XenDesktop містить в своєму складі Provisioning server, що дозволяє кільком робочим станціям одночасно завантажуватися з еталонного образу операційної системи, що зберігається в мережному сховищі.

Варто зазначити, що будь-яке з цих рішень в повній мірі може працювати з аналогічними рішеннями сторонніх виробників, тобто XenDesktop може доставляти користувачу робочі станції, віртуалізовані за допомогою VMWare або Hyper-V, а Microsoft System Centre може ефективно керувати серверами, віртуалізованими за допомогою XenServer.

Комбінація всіх перерахованих продуктів дозволяє створити повноцінну інфраструктуру доставки прикладних програм, що здатна оперативно та надійно надавати співробітникам компанії необхідні інструменти ведення бізнесу.

Прикладом роботи такої інфраструктури може слугувати наступний сценарій.

Користувач, що має в своєму розпорядженні тонкий клієнт, виконує вхід в систему під своїм обліковим записом. Агент відразу встановлює з’єднання з сервером XenDesktop, котрий на основі повноважень користувача визначає доступні для використання віртуалізовані робочі місця. Варто зазначити, що задля економі простору сховища віртуальні робочі станції не мають навіть власних дисків, і завантажуються з певного «золотого» образу (обраного, знову ж таки, на основі облікового запису користувача), розміщеного на Provisioning сервері. В образі ОС не встановлено жодних прикладних програм. А що ж там встановлено крім самої ОС? Все просто – там встановлено агент XenApp, що публікує необхідні для користувача прикладні програми на його віртуальному робочому місці. В результаті, після входу до системи користувач одержує віртуальну робочу станцію з повним набором необхідних йому прикладних програм. Для повноти картини можна додати, що всі сервери, задіяні в процесі також є віртуальними і працюють від керівництвом гіпервізора XenServer.

На завершення відзначу, що загальне враження від конференції залишилося дуже позитивним. Не зіпсував його навіть той факт, що анонсована секція практичних робіт з XenApp виявилася повністю провальною внаслідок нескоординованих дій технічного персоналу.