Light-electric.com

IT Журнал
2 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Client access server

Новая служба RPC Client Access Service в Exchange 2010 (часть 1)

Введение

Среди архитектурных нововведений, привнесенных в Exchange Server 2010, есть и новая служба клиентского доступа RPC Client Access Service, изменяющая знакомую нам бизнес-логику клиентского доступа. Эта новая служба передает почтовые соединения Outlook MAPI от back-end»ных почтовых серверов и доступ к каталогам от контроллеров доменов/серверов глобальных каталогов на уровне данных к серверам Client Access промежуточного звена.

В этой статье мы начнем с ностальгического обзора бизнес-логики во времена Exchange 2000/2003 с ее концепцией front-end»ных и back-end»ных серверов. Потом поговорим об улучшениях, внесенных при введении серверной роли Client Access в Exchange 2007. После этого мы вплотную займемся новой службой RPC Client Access Service из Exchange 2010. Мы узнаем, как работает эта служба, и как можно назначить статические порты для MAPI-соединений.

Краткий обзор архитектуры front-end»ов и back-end»ов в Exchange 2000/2003

В Exchange 2000 и 2003 у нас была базовая архитектура front-end»ов и back-end»ов, в которой front-end-серверы принимали запросы от клиентов и передавали их back-end-серверам для обработки. Front-end-сервер в Exchange 2000/2003 мог передавать RPC на базе HTTP (сейчас это называется Outlook Anywhere), HTTPS (OWA, Entourage и т.д.), POP и IMAP соответствующим back-end-серверам. Front-end-серверы также поддерживали множественные обращения к данным общей папки на back-end-серверах.

В Exchange 2000/2003 внутренние клиенты Outlook MAPI вообще не использовали front-end-серверы, они напрямую соединялись с back-end-серверами с помощью MAPI на базе RPC. И вообще, так как компонент DSProxy не запускался на front-end-серверах, у вас не было возможности указать клиентам Outlook MAPI NetBIOS-имя или FQDN front-end-сервера.

В Exchange 2000/2003 компонент DSAccess также получал доступ к службе Netlogon на серверах контроллера домена и глобального каталога в Active Directory непосредственно с помощью Remote Procedure Call (RPC), а затем клиенты Outlook подключаются прямо к DC/GC. Outlook 2000 и более ранние версии подключались к DSProxy.

Одним из преимуществ front-end-серверов в Exchange 2000/2003 было то, что они позволяли вам настраивать одно пространство имен (например, mail.domain.com). В таком пространстве имен пользователям не нужно было знать имя сервера, на котором хранился их почтовый ящик. Другим преимуществом было то, что шифрование и дешифрование SSL было отдано front-end-серверам, что освобождало дорогое процессорное время back-end-серверов. Но все-таки front-end-серверы были всего лишь прокси-серверами, которые сами ничего не обрабатывали. Они лишь производили аутентификацию и отправляли запросы на доступ к back-end-серверам; при этом сказывались еще и ограничения 32-битной архитектуры, которая, помимо прочего, ограничивала максимальный объем памяти серверов Exchange 2000/2003 до 4ГБ.

Общая информация о серверной роли Client Access в Exchange 2007

Когда был выпущен Exchange 2007, все значительно улучшилось. Смысл введения роли Client Access Server (CAS) в Exchange 2007 был в том, чтобы оптимизировать работу серверной роли Mailbox. В отличие от front-end-серверов в Exchange 2007, роль CAS — это не просто прокси-сервер. Например, серверу CAS достается обработка бизнес-логики политик Exchange ActiveSync Policies и сегментации OWA. Кроме того, рендеринг UI OWA также происходит на сервере CAS, а не на сервере Mailbox. Вообще, все клиентские соединения, кроме Outlook (MAPI) используют серверы CAS в качестве конечной точки соединения в инфраструктуре Exchange 2007. Это снимает большую часть нагрузки, которая лежала на back-end-почтовых ящиках в Exchange 2000/2003.

Затем появляется служба PRC Client Access Server в Exchange 2010

В Exchange 2010 все заходит еще дальше. В Exchange 2010 соединения MAPI и соединения с каталогами также отданы роли CAS. Это реализовано с помощью новой службы в CAS, известной как служба RPC Client Access.

Это значит, что клиенты MAPI теперь не подключаются непосредственно к серверу Mailbox, когда они открывают почтовый ящик. Вместо этого они подключаются к службе RPC Client Access, которая далее обращается к Active directory и серверу Mailbox. Для получения информации по каталогу Outlook подключается к конечной точке NSPI на сервере Client Access Server, а затем NSPI обращается к Active Directory через соответствующий драйвер. Как известно, конечная точка NSPI замещает компонент DSProxy в Exchange 2007.

Чем это отличается от клиентов Outlook Anywhere (RPC на базе HTTP), подключающихся к почтовому ящику в Exchange 2007? Ну, хотя клиенты Outlook Anywhere подключались к компоненту RPC Proxy на сервере CAS, они также обращались с помощью MAPI на базе RPC напрямую к серверу Mailbox и к конечной точке NSPI в Active Directory.

Кто-нибудь из вас обязательно поинтересуется, каковы же преимущества службы RPC Client Access. Их несколько. Во-первых, так как MAPI-соединения и соединения с каталогами отошли к роли Client Access Server (промежуточное звено), у Exchange теперь есть только один общий путь, через который происходит передача всех данных. Это не только улучшает целостность при применении бизнес-логики у клиентов. Это упрощает работу с клиентом при перенастройке или при сбоях в случае, если вы установили высокодоступное решение, использующее функцию Database Availability Group (DAG), о которой я расскажу подробнее в последующих статьях. Если пользователь клиента Outlook и заметит отключение, оно будет длиться не более 30 секунд; в Exchange 2007 это занимало несколько минут, дело могло дойти до получаса при наличии сложной топологии AD, состоящей из множества узлов AD и контроллеров доменов, с помощью которых работал DNS.

И, наконец, наличие одного пути доступа к данным позволяет увеличить число одновременных соединений и почтовых ящиков на почтовом сервере. В Exchange 2007 почтовый сервер мог работать с 64000 соединений, а в Exchange 2010 это число увеличено до 250000.

Массивы CAS в Exchange 2010

Теперь, когда в инфраструктуре Exchange 2010 большая роль отводится серверам Client Access Server, клиентам необходимо уметь быстро переподключаться к другому серверу CAS в случае, если тот сервер, с которым они работали, отключается по плановым или внеплановым причинам. Знакомьтесь с новой функцией Exchange 2010 — массивом Client Access! Как ясно из названия, это массив серверов CAS. Точнее, это массив, состоящий из всех серверов CAS в том узле Active Directory, где создавался этот массив. То есть, вместо подключения к FQDN сервера CAS, клиент Outlook может подключиться к FQDN массива CAS (например, outlook.domain.com). Это гарантирует, что у клиентов Outlook, соединенных через MAPI, соединение не пропадает даже в случае сбоя базы данных почтовых ящиков и в случаях перенастройки.

Вот как все это работает в отношении массивов CAS. В базе данных почтовых ящиков в Exchange 2010 есть атрибут под названием RpcClientAccessServer. При создании новой почтовой базы данных в узле Active Directory, где массив CAS не был создан, этот атрибут получает значение первого сервера CAS, установленного в данном узле AD. Значение данного атрибута можно посмотреть, запустив следующую команду:

Get-MailboxDatabase / fl RpcClientAccessserver

Если массив CAS существует в узле AD, при создании новой почтовой базы данных атрибут автоматически устанавливается на FQDN массива CAS. Поэтому массиву CAS известно, на какой почтовый сервер и на какую базу данных нужно направлять пользователя.

Читать еще:  Функции базы данных access

Массив CAS настраивается следующим образом. Сначала происходит создание массива CAS при помощи следующей команды:

New-ClientAccessServer ‘Name ‘название массива CAS’ ‘Fqdn -Site

После создания массива CAS вам нужно создать запись в вашем внутреннем DNS под названием outlook.domain.com, указывающую на виртуальный IP-адрес вашего внутреннего решения по балансировке нагрузки.

Все еще можно использовать Windows NLB вместе с массивом CAS, поскольку серверная роль Mailbox не установлена на той же машине, и все почтовые базы данных на сервере не защищены Database Availability Group (WNLB и кластеризация могут при этом конфликтовать, поэтому такой сценарий не поддерживается). Вы, конечно, также можете решить использовать массив CAS вместе с внешними устройствами балансировки нагрузки, что рекомендуется, особенно в случае, если у вас более 8 узлов CAS.

Если вы пользуетесь WNLB, есть резон в создании кластера WNLB, при этом нужно занести в DNS запись с указанием на WNLB VIP и убедиться в том, что TCP-порт 135 (EndPoint Mapper) и динамический диапазон RPC (TCP 1023-65535) добавлены в список правил для портов.

Замечание: Далее в этом цикле статей я покажу вам, как установить статические порты для MAPI и для доступа к каталогам.

Если вы пользуетесь третьесторонним решением для балансировки нагрузки, вам необходимо создать правила на соответствующем устройстве, работающем с round-robin-трафиком, для нужных портов.

И, наконец, если вы создавали почтовые базы данных на серверах Mailbox в узле AD перед тем, как создавать массив CAS, вам следует поменять FQDN, указанный в атрибуте RpcClientAccessServer, для этих баз данных. Это делается при помощи следующей команды:

Set-MailboxDatabase -RpcClientAccessServer ‘outlook.domain.com’

Теперь outlook.domain.com у нас должен быть виден как FQDN.

Если вы защищаете почтовые базы данных с помощью Database Availability Group, и копия соответствующей базы данных на другом узле AD становится активной, не забывайте, что серверы CAS напрямую обращаются к серверу Mailbox, на котором располагается почтовая база данных. Это взаимодействие будет происходить с помощью RPC, поскольку и серверы CAS, и серверы Mailbox работают с RPC. Это важное обстоятельство. Если весь узел прекратит работу, клиенты не будут автоматически переподключаться к серверам CAS на другом узле. Это потребует ручного вмешательства. Такая тема заслуживает отдельной статьи и выходит за рамки данной статьи.

Наконец, не забывайте, что массив CAS используется только клиентами Outlook MAPI для подключения к почтовым ящикам, общим папкам и active directory. Вам все еще нужен WNLB или внешним балансировщиком нагрузки для OWA, Autodiscover, Exchange ActiveSync, службы доступности и так далее.

Это все, чем я хотел поделиться с вами в первой части; ждите выхода второй части этого цикла статей — ее опубликуют в скором будущем.

Для системного администратора

Настрока массива серверов клиентского доступа в Exchange 2010

В одном из предыдущих постов мы вкратце рассмотрели настройку Database Availability Group в Exchange 2010. В этой статье я расскажу как настраивать Exchange 2010 RPC Client Access Array. Предыдущие версии Exchange (Exchange 2000/2003) не поддерживали использование front-end серверов для внутренних MAPI клиентов. Они должны были подключаться непосредственно к внутренним Back-End серверам через MAPI over RPC.

В Exchange Server 2010 все протоколы проходят через сервера клиентского доступа (Client Access Server) и не могут быть подключены непосредственно к серверу почтовых ящиков. Это стало возможно благодаря новой службе RPC Client Access.

Для настройки массива серверов клиентского доступа в Exchange Server 2010 CAS вы должны выполнить следующие 5 шагов, которые мы рассмотрим ниже..

  1. Необходимо настроить внутреннее DNS имя для CAS массива.
  2. Вы должны настроить Network Load Balancing.
  3. Создать новый массив клиентского доступа.
  4. Настроить базы почтовых ящиков на использование нового массива.
  5. Убедиться что служба Autodiscover правильно работает с массивом

Шаг 1 – Configure Internal DNS

1) Откройте консоль DNS и добавьте новую “A Record(Host)” запись для массива серверов клиентского доступа. Я указал в качестве имени “Client” и IP адрес 200.200.201.120

Шаг 2 – Настройка Network Load Balancing для CAS Array.

2.1) Вы должны установить Windows Network Load balancing на тех CAS серверах, которые вы предполагаете использовать в массиве. Запустите следующие команды в Powershell.

В результате мы видим что NLB успешно установлено.

2.2) Запустите Network Load Balancing Manager – Start / All Programs / Administrative Tools/ Network Load Balancing Manager.

2.3 ) Нажмите Cluster –> New для создания нового NLB кластера. В секции Host добавьте Netbios имя или IP адрес первого сервера CAS. В моем сценарии это “EX10-CAHT”. Затем нажмите Next.

2.4) Далее вы видите параметры NLB кластера. Оставьте все по умолчанию. Нажмите Next.

2.5) Теперь вы должны добавить IP адрес массива CAS. Все клиенты будут подключаться именно к этому адресу и вы должны указать тут IP, ранее прописанный нами в DNS. В моем случае это 200.200.201.120.

2.6) В этом окне вы должны добавить Full Internet Name и выбрать Cluster Operation Mode. В качестве полного имени укажем внутренний FQDN и выберем режим Multicast.

2.7) Окно Port Rules оставьте без изменений.

2.6) Добавляем следующий сервер клиентского доступа к NLB. Нажмите правой кнопкой по имени кластера и выберите Add Host to Cluster. В этом сценарии второй сервер называтеся EX10-CAHT02.

Теперь наш Windows NLB создан.

Шаг 3 – Создание массиива серверов клиентского доступа

3.1) Сначала проверим, не создано ли у нас уже массивов клиентского доступа следующей командой

3.2) Если массивов не создана, создадим самостоятельно.

Теперь мы закончили создание NLB и CAS массива . Далее нам необходимо ассоциировать почтовые базы с новым CAS массивом.

Шаг 4 – Добавление почтовый баз в Client Access Server Array

В качестве финального шага нам необходимо добавить почтовые базы в массив серверов клиентского доступа.

4.1) В примере ниже мы добавим одной командной все почтовые базы в массив CAS

Интересные ссылки:

Офигенно красивые коллекционные модели в масштабе 1:18 – моя новая хотелка.

Этот пост December 18, 2009 at 6:25 pm опубликовал molse в категории Exchange 2010, Shell и скрипты. Желающие могут оформить RSS подписку на комменты. Both comments and trackbacks are currently closed.

Клиентский доступ в Exchange Server: администрирование сервера

В данной статье я рассматриваю администрирование сервера клиентского доступа, в частности отвечаю на вопрос, что необходимо для реализации текущего мониторинга на регулярной основе, чтобы обеспечить работу серверов клиентского доступа в оптимальном режиме, и что делать, если что-то пойдет не так

Пятница, на часах 16.55, вы закругляетесь с делами и готовитесь покинуть офис, как вдруг… звонит телефон. Вы отвечаете на звонок: оказывается, у пользователей трудности с подключением к почтовым ящикам через Outlook Anywhere. Что делать? И как предупредить эту проблему в дальнейшем? .

Читать еще:  Массивы в vba access

Ваши серверы клиентского доступа составляют только часть инфраструктуры Exchange Server 2010. Другие роли сервера Exchange постоянно требуют равного или даже большего внимания, и в каждой роли есть свой фокус для администрирования. Поскольку главная функция роли клиентского доступа — облегчать соединение для почтовых клиентов, все должно быть без каких-либо неожиданностей, ведь ваша цель в управлении этой ролью — гарантировать, что клиенты могут успешно подключаться к организации Exchange и получать доступ к своей корреспонденции. Администрирование сервера клиентского доступа подразумевает три основные задачи:

  1. Управление настройками сервера клиентского доступа.
  2. Текущий мониторинг эффективной работы сервера и диагностика.
  3. Решение возникающих проблем.

Управление настройками роли

Даже после того как серверы клиентского доступа запущены и работают, вам, по всей вероятности, потребуется периодически настраивать их параметры. Сервер клиентского доступа имеет множество настроек, которыми вы можете управлять; самые основные из них отображаются через Exchange Management Console (EMC). Для менее общих настроек следует использовать Exchange Management Shell (EMS), либо удаленно, либо с сервера Exchange.

Вы можете дистанционно управлять серверами клиентского доступа одним из двух способов. Первый из них заключается в установке Exchange Management Tools на своей рабочей станции. Этот инструмент предоставит вам такие же функции, как если бы вы непосредственно подсоединились к серверу клиентского доступа. Однако он имеет кое-какие ограничения, и, наверное, самое большое из них состоит в том, что его установка возможна только на 64-разрядной рабочей станции. Если ваши администраторы используют 32-разрядные клиенты Windows или Windows XP, эта стратегия удаленного управления не будет работать. Однако если вы работаете с 64-разрядной клиентской системой под управлением Windows Vista SP2 или более новыми версиями либо 64-разрядной серверной системой под управлением Windows Server 2008 R2 или Windows Server 2008 SP2, то можете установить Exchange Management Tools. Чтобы установить данный инструмент, запустите setup.exe с установочного диска Exchange, выполните настраиваемую установку и выберите Exchange Management Tools, как показано на экране 1. В качестве альтернативы для установки инструмента можно воспользоваться методом автоматической установки. Введите следующую команду:

Второй путь — использовать удаленно PowerShell. PowerShell на удаленном Exchange 2010 предоставит дистанционный доступ с любой рабочей станции, на которой установлен PowerShell 2.0 и Windows Remote Management (WinRM) 2.0. Затем можно удаленно запустить команды EMS на серверах клиентского доступа. Одно из преимуществ использования данного подхода заключается в том, что вы можете управлять серверами клиентского доступа с 32-разрядной клиентской системы. Диапазон поддерживаемых клиентских версий Windows также расширяется благодаря этому способу, потому что удаленно PowerShell можно использовать на таких старых операционных системах, как XP или Windows Embeded. И PowerShell 2.0, и WinRM 2.0. доступны в пакете Windows Management Framework Core, который можно загрузить по адресу support.microsoft.com/kb/968929.

Windows Management Framework Core может быть установлено как на 32-, так и на 64-разрядных операционных системах, работающих под управлением XP SP3, Windows Vista SP1 или более новых версий.

После установки Windows Manage­ment Framework Core вы можете использовать PowerShell 2.0 для удаленного соединения с серверами клиентского доступа через удаленный виртуальный каталог PowerShell. Когда вы дистанционно подключаетесь к PowerShell, клиент загружает команды, к которым имеет доступ ваша учетная запись, и запускает их на рабочей станции. Эти команды в действительности работают на сервере клиентского доступа в фоновом режиме, но все выглядит так, как будто они запускаются на рабочей станции. Если вы подсоединились к компьютеру в домене и у вас есть SSL, активированный для виртуального каталога PowerShell, вы можете воспользоваться следующими командами с консоли PowerShell на своей рабочей станции, чтобы удаленно установить соединение:

Мониторинг производительности и диагностика

Контролируя сервер клиентского доступа, вы можете максимально автоматизировать процесс. Подключаться и вручную проверять состояние серверов — ненужная трата времени. У нас есть несколько программных продуктов мониторинга, включая Microsoft System Center Operations Manager и Quest Software Spotlight on Messaging. Если можно отслеживать сервер клиентского доступа без дополнительного программного обеспечения, вы можете воспользоваться встроенным инструментарием Windows, однако необходимо заранее позаботиться о запуске мониторинга. Вы должны сосредоточиться на нескольких вещах, контролируя инфраструктуру серверов клиентского доступа.

Администраторы Exchange зачастую сразу обращаются к средствам устранения неполадок или проводят расширенную диагностику, когда возникает проблема. Однако можно осуществлять мониторинг своих серверов клиентского доступа с помощью журналов событий Windows, поскольку они могут уже на раннем этапе подать сигнал тревоги, если что-то не так. Exchange записывает события в журнал приложений. Вы можете проверять системный журнал на предмет наличия предупреждений и ошибок, которые имеют отношение к базовой операционной системе. Иногда ошибка, вероятнее всего, связана с Windows Server, а не с Exchange. В частности, необходимо уделять пристальное внимание событиям, относящимся к протоколам клиентского доступа, Аutodiscover и адресной книге. Когда сбои возникают на серверах клиентского доступа, образуются обычные проблемные области. Если что-то происходит с IIS, это может повлиять на доступ клиентов через Outlook Anywere App (OWA), Exchange ActiveSync, Exchange Web Service и Outlook Anywere, поэтому важно сохранять работоспособность IIS. Ошибки клиентского доступа по RPC не проявляются через IIS, так что важно как можно скорее разобраться с сообщениями об ошибках, источником которых является MSExchange.

Другая вещь, которую необходимо отслеживать, это производительность серверов клиентского доступа. Вы можете собрать информацию о «железе» и службах, чтобы убедиться, что они работают в пределах пороговых величин. Можно задействовать монитор производительности Performance Monitor, perform.exe, чтобы собрать всю информацию. Монитор производительности использует счетчики, которые Exchange Server делает доступными.

Вы можете отслеживать аспекты эффективной работы аппаратного обеспечения, а заодно и обслуживать конечные точки служб серверов клиентского доступа. Таблица 1 идентифицирует несколько ключевых счетчиков, которые нужно принять во внимание во время мониторинга производительности аппаратного обеспечения. Таблица 2 содержит объекты счетчиков производительности, которые связаны с конечными точками служб сервера клиентского доступа.

Установка Client Access Server Array в Exchange 2010

Впервые роль Client Access Server (CAS) появилась в Exchange Server 2007. Основная цель сервера с этой ролью – обработка клиентских подключений к почтовым ящикам, которые создаются клиентами Outlook Web Access, Outlook Anywhere или ActiveSync.

Однако сервера с почтовыми ящиками (роль Mailbox) все еще отвечали за непосредственные MAPI подключения, которые создаются, например, клиентом Microsoft Outlook.

В Exchange Server 2010 данная архитектура несколько изменилась, теперь в роль Client Access Server добавлена служба RPC Client Access. Данная служба обрабатывает все MAPI подключения, которые генерируют клиенты Outlook при работе с почтовым ящиком (подключение к общим папкам, Public Folder, все еще осуществляется напрямую к серверу-хранилищу почтовых ящиков).

Новая служба RPC Client Access обеспечивает ряд преимуществ:

  • Подключения к ящикам осуществляются единообразно
  • Возможность регулировать клиентские подключения (Connection throttling) и применять к ним другие правила
  • Уменьшение неудобств пользователей, вызванных отказом их почтового сервера
Читать еще:  Строка подключения к access

Для организаций, которые хотят добиться высокой доступности (high availability) службы RPC Client Access, несколько серверов CAS можно объединить в массив, балансировку нагрузки в котором можно организовать с помощью Windows Network Load Balancing (NLB) или же аппаратного балансировка.

В данной статье мы пошагово опишем процесс построения массива серверов CAS Exchange Server 2010 (Client Access Server array) c балансировкой нагрузки между ними посредством Windows NLB.

Требования к Client Access Server Array

Два и более серверов Exchange 2010 с ролью Client Access можно объединить в массив CAS с NLB только тогда, когда на них не установлена роль сервера почтовых ящиков (Mailbox), являющегося членом Database Availability Group (DAG). Причина в том, что члены DAG используют кластеризацию на базе Windows Failover Clustering, которую нельзя использоваться совместно с NLB.

Пусть у нас имеется два сервера, на которых мы хотим построить массив CAS.

Сервер 1

  • ОС: Windows Server 2008 64-bit R2
  • Имя сервера: EX3.exchangeserverpro.local
  • Первичный сетевой интерфейс: 192.168.0.34/24
  • Первичный сетевой интерфейс: 192.168.0.36/24

Сервер 2

  • ОС: Windows Server 2008 64-bit R2
  • Имя сервера: EX4.exchangeserverpro.local
  • Первичный сетевой интерфейс: 192.168.0.35/24
  • Первичный сетевой интерфейс: 192.168.0.37/24

NLB кластеру назначим IP адрес 192.168.0.38.

Установка компонентов Client Access Server

На каждом из серверов в командной строке PowerShell с правами администратора нужно выполнить следующие команды:

(опция –Restart означает необходимость перезагрузить сервер после установки компонентов). После перезагрузки сервера, выполняем:

Установка роли Client Access Server в Exchange Server 2010

Для установки роль CAS, а также набора Management Tools, в командной строке с правами администратора выполните команду:

Установка службы Windows Network Load Balancing

На каждом из серверов выполните следующие команды PowerShell:

Создаем NLB кластер

После подготовки обоих серверов, перейдем к созданию и настройке NLB кластера. На первом сервер откройте консоль управления Network Load
Balancing Manager
(находится в Administrative Tools).

В меню Cluster выберите New.

Подключитесь к первому серверу кластера NLB.

Выберите интерфейс, который будет использоваться кластером, затем нажмите Next.

Оставьте все параметры первого узла по-умолчанию и нажмите Next.

Нажмите Add
и введите IP (v4) адрес NLB кластера и затем OK.

Нажмите Next.

Введите имя кластера, например casarray.exchangeserverpro.local. Нажмите Next.

Затем можно настроить различные правила для портов, но в данном случае мы оставляем стандартные правила. Чтобы создать NLB кластер, нажмите Finish.

На данный момент наш NLB кластер состоит из одного сервера, необходимо добавить второй сервер CAS.

Щелкните правой кнопкой мыши по недавно созданному кластеру и выберите Add Host to Cluster.

Укажите имя второго сервера и нажмите Connect. И опять выберем сетевой интерфейс, который будет использоваться кластером, нажмите Next.

Оставьте стандартные настройки и нажмите Next.

В результате в NLB кластер был добавлен второй узел.

Создаем массив серверов Client Access

После создания NLB кластера, перейдём к созданию массива серверов CAS Exchange Server 2010.

Во-первых, зарегистрируем в DNS запись для имени NLB кластера.

Во-вторых, на любом из серверов откройте консоль Exchange Management Shell и выполните:

Обновляем базу данных почтовых ящиков

После создания массива CAS, для любой новой почтовой базы, создаваемой в этом же сайте Active Directory, в качестве сервера, обрабатывающего RPC запросы (RpcClientAccessServer) к ящикам в этой базе будет указан созданный нами массив CAS.

Однако все существующие почтовые базы придется обновить вручную, так, чтобы пользователи ящиков в этих базах подключались к созданному нами массиву серверов.

Name : Mailbox Database 02
RpcClientAccessServer : EX3.exchangeserverpro.local

Как вы видите, текущая почтовая база на сервере EX2 настроена на использование в качестве RpcClientAccessServer одиночного CAS сервера.

Чтобы обновить все базы на сервере, необходимо выполнить команду:

Проверить текущий статус можно с помощью той же самой команды:

Клиент — сервер

OLE. Access -клиент, Word — сервер. Работает через раз. «Сервер не валиден!»
Задача: получить путь прилинкованного файла. Тип OLE — связанный Рамка объекта — присоединенная.

Клиент-Сервер «MSAccess-MySQL»
Всем привет. Может кто подскажет, как из MSAccess подключиться к MySQL? Заранее благодарен.

Создание пользователей сервер/клиент
Есть база. Она будет представлена как серверная и клиентская части. Но как создать.

Как сохранить настройки(Сервис/Параметры/Правка и поиск/Подтверждение) в разделенной БД(клиент-сервер)
Доброго времени суток! Пользователи БД высказали пожелание убрать всплывающие окна "Запрос на.

пользователь не сможет таблицы открыть? с паролями и т.д.

Добавлено через 3 минуты
и как правильно скрыть таблицы, запросы и все что в области навигации

Вот здесь — Access 2013 — что за зверь? — утверждается, что поддержки ADP в 2013 нет.

И добавлю насчет предложенном выше разделении БД на клиентскую и серверную часть. Это не является технологией «клиент-сервер» в полной мере. Файл-серверное исполнение запросов на клиенте остается, в клиентскую часть отдаются исходные данные, а не результат запросов. Частично файл-серверная технология конечно тоже усовершенствовалась, если данные уже есть в кэше, то заново не передаются. Но все равно это не полный функционал клиент-сервера.

И тогда, если юзеры не слишком уж «прошаренные» — они не найдут, где можно полазить в таблицах, запросах и т.д.)
А можно еще вообще скрыть всю оболочку Акса, оставив на экране только формы самой базы. Если интересно, кину ссылку. Тут на форуме есть такое.

Добавлено через 1 минуту
mobile, Мне почему-то кажется, что ТС вполне будет достаточно именно такого вот разделения, которое есть в Access. Скорее всего он именно это и подразумевал в своем вопросе.

сейчас пока смотрю про Runtime, отлично работает вроде (стандартно разделил) и все скрыто.
что думаете по поводу runtime?
только проблема, что путь к базе с таблицами посмотреть не проблема(((

надо чтоб все работало нормально, это главное

Добавлено через 57 минут
как вообще это правильно сделать?
задача клиент — сервер сделать, чтоб сервер был в корпоративной сети.

Добавлено через 2 минуты
точнее общий сетевой диск

Как скрыть окно Access, чтобы показывались только формы — вот в этой теме описана процедура, которую надо добавить в базу. При этом важно — все формы нужно сделать всплывающими.

Вполне нормально работает, я не замечал нареканий вроде бы.

При такой организации работы баз — вполне нормально работает.

Встроенными средствами Акса разделяете базу на две. Серверную часть кладете на сетевой диск, клиентские части — на каждый комп.
Обеспечиваете линковку таблиц. Тут два варианта:
1. Воспользоваться штатным Диспетчером связанных таблиц. Т.е. один раз запустить на машине клиента, выделить все таблицы, указать, где лежит файл с таблицами, оно прилинкует.
2. Написать код автолинковки (тут на форме по-любому есть образцы, можно выбрать на свой вкус и допилить под себя), прицепить этот код, например, на макрос autoexec, или на свойство загрузки главной формы базы.

Ссылка на основную публикацию
Adblock
detector