Configure rds user profile disks on windows

Введение.

После основной конфигурации терминальной фермы, профиль пользователя нужно централизованно подгружать на каждый из серверов сеанса удаленного рабочего стола. По умолчанию используется User Profile Disks начиная с Windows Server 2012R2, конечно мы не говорим об устаревших технологиях по типу перенаправляемых профилей\папок, но также есть и другие решения, в данном случае мы применяем FSlogix.

FSLogix Profile Container преобразует профиль пользователя в VHD\X-файл и перенаправляет его на общий сетевой ресурс (Fileshare). Пока пользователь входит в систему, агент подключается к FileShare и проверяет, существует ли VHD\X-файл для вошедшего в систему пользователя. Если это так, то виртуальный диск монтируется к папке C:\Users\. Если соответствующий VHD\X-файл не найден в FileShare, для пользователя создаётся и монтируется новый VHD\X-файл.

Профили

У каждого пользователя Powershell есть свой профиль. Профиль выглядит как обычный файл со скриптом формата ps1. Открывая консоль Powershell вы автоматически запускаете этот файл и все значения, перечисленные в файле профиля, становятся видимыми для вас. Кроме этого профиль не ограничивается одним пользователем и может использоваться для всех.

Создание

Каждый профиль пользователя хранится в файле «.ps1» и путь до него можно посмотреть используя встроенную переменную:

Вы можете открыть этот файл и вписать в него любую команду. Я использую команду, которая проверит соединение с DNS сервером Google:

Теперь, каждый запуск консоли будет выводить следующее, дополнительное, сообщение:

Отмечу, что это не самый удачный пример т.к. эта команда занимает существенное время на выполнение. Вы вряд ли захотите ждать 4-5 секунд для запуска консоли.

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

Самый быстрый вариант, при котором вам не нужно будет дожидаться загрузки, это создание функции совмещающей все ваши базовые задачи. Она будет вызываться только при обращении к ней:

Типы профилей

Если посмотреть содержание переменной $Profile более детально, то мы увидим 4 типа профилей:

В выведенной информации можно увидеть понятие ‘host’. Под «хостом» подразумевается программа, которая хостит Powershell. Это может быть стандартная консоль, редактор ISE, VisualStudio и т.д.

Мы так же увидим следующие профили:

AllUsersAllHosts — профиль для всех пользователей и для всех хостов;
AllUsersCurrentHost — профиль для всех пользователей и только для текущего хоста;
CurrentUserAllHosts — профиль для текущего пользователя и для всех хостов;
CurrentUserCurrentHost — профиль для текущего пользователя и только для этого хоста.

Указанный путь — это место, где уже есть или может быть создан файл. При каждом запуске Powershell проверяет эти пути и читает данные.

Наиболее просто будет понять разницу работы профилей на примере. В каждый файл профиля я поместил команду соответствующую его названию:

Запуск средства разработки Powershell ISE и обычной консоли был следующий:

Как видно, в ISE, отображаются не все профили. Связано это с тем, что консоль Powershell и редактор ISE — это разные хосты. Мы можем увидеть немного отличающиеся профили если запустить эту команду в ISE:

Так же вы можете увидеть дополнительные профили если используете Powershell Core 6/7, VisualStudio и т.д..

Профиль при удаленном подключении

Прямых способов использования профилей при удаленном подключении нет. Есть косвенный способ, который заключается в возможности использования файлов со скриптами в команде «Invoke-Command». Следующий пример демонстрирует такую возможность:

На самом деле эта команда выглядит следующим образом:

Вам так же будет интересно:

VHDX файл с UPD профилем пользователя

Перейдем в наш общий сетевой каталог с профилями пользователей. Теперь в нем хранится файл вида UVHD-template.vhdx.

Этот файл представляет собой шаблон диска с профилем пользователя. При первом RDP входе пользователя на сервер RDS, этот шаблон копируется и переименовывается в vhdx файл, содержащий в имени SID пользователя.

Совет. Теперь, чтобы сопоставить имя файла UPD с именем пользователя, приходится пользоваться отдельным скриптом. Например, ShowUPDFolderDetails.ps1 или можно преобразовать SID в имя учетной записи с помощью командлета Get-ADUser:

Посмотрим, что представляет собой диск с профилем пользователя. Для этого смонтируем его, щелкнув по vhdx файлу ПКМ и выбрав пункт Mount. Диск UPD можно использовать только в одной сессии на одном RDS хосте (монопольный доступ). Вы не сможете смонтировать UPD VHDX диск, если в настоящий момент его использует пользователь на RDS сервере).Как вы видите, содержимое vhdx диска представляет набор каталогов и файлов обычного профиля пользователя. При входе в систему пользователь получает абсолютно прозрачный доступ к данным, хранящимся в его профиле.

На стороне сервера RD Session Host .vhdx файл пользователя монтируется в каталог C:\users\> и выглядит таким образом:

Обратите внимание, что UPD диск привязан к версии Windows RDS сервера. Вы не сможете перенести UPD профиль пользователя с RDS сервера с одной версии Windows Server на другую

Запись данных в файл vhdx ведется в реальном времени. Т.е. при копировании данных в профиль пользователя на сервере RDS, размер vhdx файла на общем хранилище увеличивается сразу.

В том случае, если в системе уже присутствует каталог с профилем пользователя, каталог со старым профилем переименовывается в формат username>-BACKUP->.

VHDX диск монтируется при старте сессии пользователя на VDI или RDS сервере. Список подключенных UPD дисков с профилями можно вывести с помощью утилиты mountvol.

По-умолчанию диск с пользовательским профилем содержит в себе все содержимое профиля пользователя. Однако, в настройках RDS коллекции можно исключить определенные папки из списка синхронизируемых каталогов, либо указать, что должны сохранятся только определённые папки. Таким образом все изменения, которые вносятся в терминальной сессии пользователя в список исключенных папок профиля, не сохраняются на vhdx диске в сетевом каталоге.

Второй вариант позволяет настроить сохранение в UPD профиле только указанных каталогов.

В случае необходимости, второй вариант позволяет реализовать сценарии сохранения настроек стартового экрана, хранящихся в файле appsfolder.itemdata-ms. В данном примере мы просто добавили путь к каталогу \AppData\Local\Microsoft\Windows в качестве дополнительного пути, который нужно сохранять в UPD.

Для чего нужные контейнеры FSLogix?

Концепция FSLogix похоже на привычную технологию RDS User Profile Disks (UPD), когда профили пользователей хранятся в виде виртуальных VHDX дисков и подключаются по сети при входе пользователя в систему. Однако FSLogix позволяет преодолеть многие недостатки UPD в средах RDS и позволяет:

Существенно увеличить скорости загрузки профиля по сети, и как следствие уменьшается время входа/выхода в систему для пользователя;
Оптимизирован для приложений Office 365 (Microsoft 365 for Enterprise);
Один и тот же профиль можно использовать в разных RDS коллекциях, и фермах RDS VDI и даже физических компьютерах;
Профиль FSLogix можно подключать сразу в несколько сессий (на чтение);
В UPD поисковый индекс Windows очищается при выходе пользователя и его нужно генерировать заново в следующий раз. В FSLogix можно сохранять индекс в перемещаемом профиле;
Обеспечивает доступность файлов кэша Outlook (OST, Outlook Cached Mode), индекса (поиска) Outlook, кэша и данных MS Teams и т.д.
Перемещаемые FSLogix профили можно исопльзовать даже на отдельностоящих хостах RDSH.

Решение FSLogix бесплатно для использования в on-premises развертываниях RDS, при условии, что у вас приобретены RDS CAL и установлены на сервере лицензирования RDS.

Планшеты с игровым процессором snapdragon или kirin
Daewoo nexia ошибка eeprom второго процессора
Оперативная память зависает ubuntu
Процессор t4500 на что заменить
Хороший ли процессор intel core i5 10400f

Расширенная настройка профилей FSLogix на Windows Server RDS

При установке агента FSLogixAppsSetup на сервере, в списке локальных групп появляются несколько дополнительных групп. Вы можете вывести этот список с помощью командлета Get-LocalGroup:

Get-LocalGroup -Name «*fslo*»

FSLogix ODFC Exclude List — Members of this group are on the exclude list for Outlook Data Folder Containers
FSLogix ODFC Include List — Members of this group are on the include list for Outlook Data Folder Containers
FSLogix Profile Exclude List — Members of this group are on the exclude list for dynamic profiles
FSLogix Profile Include List — Members of this group are on the include list for dynamic profiles

Эти группы позволяют указать пользователей или группы, для которых нужно включить или отключить создание профилей FSLogix.

По умолчанию перемещаемые профили создаются для всех пользователей. Чтобы иметь возможность локального входа на сервер для группы администраторов при неполадках FSLogix, нужно добавить группу администраторов в локальную группу FSLogix Profile Exclude List.

Проще всего это сделать с помощью групповой политики Restricted Group (Computer Configuration -> Windows Settings -> Security Settings -> Restricted Groups -> Add Group -> FSLogix Profile Exclude List) или Group Policy Preferences (Computer Configuration –> Preferences –> Control Panel Settings –> Local Users and Group –> New -> Local Group -> FSLogix Profile Exclude List).

Более подробно использование GPO для добавления пользователей в локальные группы описано в отдельной статье.

Чтобы исключить определенные каталоги из перемещаемого профиля FSLogix, вы можете использовать файл redirection.xml. Каталоги из этого файла перенаправляются в локальные папки на диске сервера.

Путь к этому XML файлу с настройками задается в параметре GPO FSLogix -> Profile Containers -> Advanced -> Provide RedirXML file to customize redirections. Можно исключить Temp папки, каталоги кеша IE, Chrome и т.д.

Пример такого файла указан ниже:

Проанализируйте профили пользователей и установленные программы и добавьте в файл новые исключения.

Добавьте исполняемые файлы FSLogix в исключения вашего антивируса (frxdrv.sys, frxdrvvt.sys, frxccd.sys, frxccd.exe, frxccds.exe, frxsvc.exe).

01.10.2018

itpro

Windows Server 2012, Windows Server 2016

комментариев 89

User Profile Disks (UPD, диски профилей пользователей) – новый функционал Remote Desktop Services в Windows Server 2012. User Profile Disks представляют собой альтернативу использованию технологий перемещаемых профилей (roaming profile) и перенаправления папок (folder redirection) в терминальных сценариях RDS. Идея UPD – данные пользователя и его приложений (т.е. его профиль) хранятся в виде отдельного виртуального vhdx диска на неком выделенном общем файловом ресурсе. Этот виртуальный диск монтируется в сессию пользователя при его входе на RDS-сервер, и отключается при выходе (конечно, с сохранением всех изменений в профиле).

В этой статье мы опишем особенности настройки и работы технологии User Profile Disks на сервере с ролью Remote Desktop Services на Windows Server 2012 / 2012 R2 / 2016.

Сведения о функциональных различиях

основа знаний — Microsoft TechNet

Пользователи:guest— обязательный профиль, самое бесправное существо. почту умеет отправлять но только от дефолтного юзера, есть адресная книга корпоративная, какое-то избранное и стартовая страница на корпоративный сайт. Сделанное не запоминается.user — обязательный профиль. почту умеет отправлять но оутлук експресс запрашивает пароль для того что-бы пользователь зашел под своим почтовым профилем, есть адресная книга корпоративная, какое-то избранное и стартовая страница на корпоративный сайт. Подключены основные сетевые диски. в принципе, можно более менее нормально работать. Сделанное не запоминается.%username% — перемещаемый профиль журналиста. Работать может где угодно в нашем офисе. все что сделал после «правильного» выхода из системы запоминается и на другом рабочем месте открывается как было при последнем выходе. Автоотключение пользователя при неактивности 30мин. Заставка через 15 минут.%adminname% — профиль обязательный, самый скромный функционал. сделан для того, чтобы настроить/перенастроить локальный компьютер. никакой другой работы — только администрирование.

На что следует обратить внимание перед настройкой дисков профилей пользователей RDS

Пользователь, подключающийся к двум разным коллекциям, будет иметь два отдельных профиля;

Свойства задаются автоматически при создании и по умолчанию содержат все данные профиля и параметры реестра.

Эти свойства можно определить до или после создания в свойствах «Коллекции сеансов» в «Диспетчере серверов»;

Необходима форма центрального общего файлового ресурса, поскольку путь UNC к этому общему ресурсу должен быть указан в мастере во время первоначальной настройки.

Одним из основных преимуществ этих общих файловых ресурсов является то, что когда для поддержки коллекции добавляется больше хостов RDS, эти хосты автоматически добавляются в ACL общего ресурса, не требуя от администратора каких-либо действий по изменению разрешений безопасности;

Если пользователь входит на один хост RDS, он не может подключиться к другому и не может иметь более одного активного сеанса на одном хосте;

Диски профилей пользователей создаются с использованием схемы именования, соответствующей GUID пользователя, что делает идентификацию UPD, связанного с пользователем, очень рискованной задачей.

Настройка дисков профилей пользователей RDS в Windows

Прежде всего необходимо создать общую папку на любом корпоративном файловом сервере для хранения профилей пользователей в виде VHDX-диска.

Например, путь к нашей папке будет таким: \\rdvh1\DemoLabOficeApp.

Серверы, входящие в состав коллекции RDS, должны иметь полное разрешение на доступ к этой общей папке.

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

Мы можем настроить диски профилей пользователей RDS в настройках сбора служб удаленных рабочих столов. Мы можем включить этот режим при создании новой коллекции.

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

Здесь. в разделе Диски профилей пользователей «Включаем» диски профилей пользователей, указываем путь к предыдущей общей папке (\\rdvh1\DemoLabOficeApps) и максимальный размер диска профилей. Затем мы сохраняем изменения.

После этого мы обязательно изменим разрешения NTFS для папки Profile Disks. В нашем случае коллекция состоит из одного сервера RDSH01, имеющего разрешение на полный доступ.

Следовательно, серверу RDSH01 на уровне общей папки предоставляются права полного доступа.

Когда мы добавляем новые серверы узла сеансов удаленных рабочих столов в коллекцию RDS, мастер автоматически изменяет права доступа к папке и предоставляет доступ к новым серверам.

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

Установка роли

Открываем Диспетчер серверов:

Переходим в Управление — Добавить роли и компоненты:

При появлении окна приветствия нажимаем Далее (при желании, можно поставить галочку Пропускать эту страницу по умолчанию):

На страницы выбора типа установки оставляем выбор на Установка ролей или компонентов:

Выбираем целевой сервер — если установка выполняется на сервере локально, то мы должны увидеть один сервер для выбора:

Ставим галочку Службы удаленных рабочих столов:

Дополнительные компоненты нам не нужны:

… просто нажимаем Далее.

На странице служб удаленных рабочих столов идем дальше:

Выбираем конкретные роли — нам нужен Шлюз удаленных рабочих столов. После установки галочки появится предупреждение о необходимости поставить дополнительные пакеты — кликаем по Добавить компоненты:

Откроется окно для настроек политик:

… нажимаем Далее.

Откроется окно роли IIS:

… также нажимаем Далее.

При выборе служб ролей веб-сервера ничего не меняем:

… и идем дальше.

В последнем окне ставим галочку Автоматический перезапуск конечного сервера, если требуется:

Нажимаем Установить:

Дожидаемся окончания установки роли:

Сервер может уйти в перезагрузку.

Установка и настройка групповых политик.

1. Установим на наш контроллер домена политики fslogix.adml и fslogix.admx из архива по пути: \oilservice.local\SYSVOL\oilservice.local\Policies\PolicyDefinitions, что бы они отреплицировались на другие КД.

2. Создаем новую политику, нацеливаем ее на объекты наших компьютеров RDSH серверов.

3. Настраиваем политику: Computer Configuration->Polices->Administrative Templates->FSLogix

FSLogix\Enable logging	Enabled. Only specifically enabled logs.Включаем основные логи работы профилей.
FSLogix\Path to logging files	Enabled. \\ADDS\Logs\%COMPUTERNAME%По этому пути создадутся подпапки с именем RDSH серверов.
FSLogix\Days to keep log files	Enabled. Days to keep log files 3.Три дня более чем достаточно.
FSLogix\Profile Containers\Store search database in profile container	Enabled. Store search database in profile container. Disabled.Отключаем сохранение базы поиска в профиле.
FSLogix\Profile Containers\Enabled	Enabled. Включаем сам FSLogix.
FSLogix\Profile Containers\VHD Location	Enabled. \\ADDS\Profiles\Путь хранения наших профилей.
FSLogix\Profile Containers\Delete local profile when FSLogix Profile should apply.	Enabled. Производит удаление локального профиля.
FSLogix\Profile Containers\Size in MBs	Enabled. Установите максимальный размер профиля. По умолчанию 30Gb.
FSLogix\Profile Containers\Advanced\Provide RedirXML file to customize redirections	Enabled. \\ADDS\RedirectionsПуть конфигурационного файла.
FSLogix\Profile Containers\Advanced\Prevent login with temporary profile	Enabled. Предотвращает создание Temp профиля.
FSLogix\Profile Containers\Advanced\Prevent login with failure	Enabled. Предотвращает вход пользователя в систему в случае сбоя при подключении контейнера FSLogix.
FSLogix\Profile Containers\Container and Directory Naming\Virtual disk type	Enabled. Выбираем VHDX диск, вместо VHD по умолчанию.
FSLogix\Profile Containers\Container and Directory Naming\Swap directory name components	Enabled. Косметическая правка, папка с профилем по умолчанию имеет имя SID_%username%, делаем обратно %username%_SID, считаю так более удобней.

4. Перезагружаем RDSH сервера. Видим в реестре, что политика применила изменения. Тестируем.

5. Вход произведен успешно. Профиль прицепился.

6. На условном нашем файловом сервере появились профили:

7. Так же создалась структура папок для логов:

А что же было не так?..

Основными же поводами и направлениями для улучшений в разрезе RDS в WS2012 были следующие вещи:

1.RemoteFX был достаточно популярным и востребованным решением, однако нижележащий протокол, RDP, не предоставлял качественного доступа и передачи данных поверх медленных и географически распределенных каналов типа WAN (Wide Area Network).2.Развертывание инфраструктуры пользователей как на базе сессий, так и на базе виртуальных машин было очень не простым и не экономически эффективным мероприятием.3.Администрирование всех компонентов и сервисов в пределах роли RDS, если не сказать сложным.

В Windows Server 2012 все вышиперечисленные моменты были кардинально переработаны, а именно:

В WS2012 RemoteFX гораздо лучше ощущает себя на WAN-канале и может автоматически подстраиваться под условия канала в зависимости от его характеристик и возможностей хоста. Также улучшения включают в себя следующие моменты:

Адаптивная графика. Под адаптивной графикой подразумевается наличие различного списка кодеков для работы с разным типом контента (для видео применяются одни кодеки, для текста — другие, для изображений — третьи). Ранее мы использовали всего один кодек, независимо от типа контента. В сочетании с этим мы также используем новую прогрессивную систему кэширования данных — что позволяет снизить задержки в работе на сильно загруженных сетях и каналах передачи данных.
Оптимизированная потоковая передача медиа-данных. Для мульти-медиа данных мы используем совершенно новый кодек, который ранее не был в нашем арсенале — в зависимости от условий положительный эффект на качестве передаваемого контента может увеличиться до 90% в сравнении с предыдущим поколением RDS.
Автоматическое адаптивное определение сети. Это изменение направлено на то, что пользователю больше не нужно вручную указывать характеристики подключения — система автоматически определяет настройки и себя конфигурирует.
Поддержка DirectX11 vGPU. В Windows Server 2008 R2 SP1, мы впервые представили RemoteFX Virtual GPU (vGPU), который поддерживал проброс DirectX 9 приложений и поддержку Aero внутри виртуальных машин на базе Hyper-V с физическими ГП (GPU). В Windows Server 2012, функция vGPU была расширена и все виртуальные машины с ОС Windows 8 могут использовать все преимущества адаптеров с поддержкой DirectX 11, а также использовать софтверный рендеринг в тех сценариях, где ГП на базе DirectX 11 физически отсутствуют в серверах с RDS. Также добавлена поддержка нескольких видеокарт в пределах одной физической системы — что существенно повышает плотность и производительность системы.
Единая точка входа. В Windows Server 2008 R2 была возможность ввести учетные данные пользователя единожды при подключении к RemoteApps или к сессиям RDP — однако настройка такой конфигурации была очень не простой. В Windows Server 2012 мы значительно упростили процесс в виду отмены необходимости использования гигантского количества сертификатов. Также если вы уже находитесь под действующей учетной записью в домене — у вас нет необходимости заново вводить ваши учетные данные — они просто-навсего будут транслированы при организации подключения.
Обнаружение ресурсов RDS с помощью электронного адреса (e-mail). теперь НЕТ НЕОБХОДИМОСТИ ЗАПОМИНАТЬ ДЛИННЫЕ url ДЛЯ РАБОТЫ С УДАЛЕННЫМИ РЕСУРСАМИ — ВСЕ ДЕТАЛИ МОЖНО ВЫЯСНИТЬ ПРОСТО УКАЗАВ СВОЙ E-MAIL, а Web Access теперь также поддерживает браузеры Chrome и Firefox наравне с IE.
Мульти-тач. RDS поддерживает полный набор жестов, которые появились в Windows 8 и для удаленных сеансов (например увеличение или открытия меню настроек)) между клиентом и хостом с разрешением до 256 касаний. Так что теперь независимо от того как вы работаете — локально или удаленно — если ваш девайс мульти-тачебельный — вы сможете работать с тач-приложениями должным образом.
Перенаправление USB. В Windows Server 2008 R2 SP1 мы поддерживали изохронный проброс USB только для виртуальных машин с активированным vGPU. В новой версии мы также добавили поддержку сценариев на базе сессий и физических хостов — тем самым предоставляя одинаковые возможности независимо от того, используете ли вы физический доступ, на базе сессий или же на базе ВМ.

Создание и назначение профилей

Управлять профилями можно через Database Control или SQL *Plus. Для просмотра текущих профилей пользователей выполните запрос

select username,profile from dba_users;

По умолчанию все аккаунты (за исключением двух внутренних аккаунтов DBSNMP и WKSYS) будут использовать профиль DEFAULT. Запрос для просмотра профиля

select * from dba_profiles where profile=’DEFAULT’;

Профиль DEFAULT не имеет ограничений на ресурсы, но существуют несколько ограничения на пароли

Эти ограничения не слишком сильные: пароль может вводится неверно 10 раз перед блокировкой аккаунта на один день, и пароль истекает через полгода с грейс периодом в неделю. Простейший способ применить более строгие ограничения к паролям это выполнить скрипт поставляемый с Oracle $ORACLE_HOME/rdbms/admin/utlpwdmg.sql. Этот скрипт создаст функции VERIFY_FUNCTION и VERIFY_FUNCTION_11G и затем выполните запрос

ALTER PROFILE DEFAULT LIMIT

PASSWORD_LIFE_TIME 180

PASSWORD_GRACE_TIME 7

PASSWORD_REUSE_TIME UNLIMITED

PASSWORD_REUSE_MAX UNLIMITED

FAILED_LOGIN_ATTEMPTS 10

PASSWORD_LOCK_TIME 1

PASSWORD_VERIFY_FUNCTION verify_function_11G;

Эта команда изменит профиль DEFAULT. Все пользователи с профилем DEFAULT (все пользователи по умолчанию) сразу подхватят новые значения. Единственным изменение будет использование функции verify_function_11G. Эта функция будет проверять пароль на соответствие определённым критериям, а именно

Новый пароль должен быть длинной не менее 8 символов
Пароль не должен совпадать с именем пользователя
Часто использумые простые пароли (к примеру oracle) будут отклонены
Новый пароль должен содержать минимум одну заглавную букву и одну цифру
Пароль должен отличаться минимум в три символа от предыдущего

Можно рассмотреть эту функцию как пример и изменить согласно вашим требованиям. Вообще желательно создать отдельные профили для разныз групп пользователей.

Для создания профиля используется команду CREATE PROFILE, устанавливая необходимые ограничения. Неустановленные значения будут выставлены в зависимости от значений в профиле DEFAULT. Например рассмотрим сценарий где пользователи могут открывать только одну сессию, администраторы могут создавать сколько угодно сессий и должны менять пароль раз в неделю с грейс периодом в день, а программисты могут открывать две сессии. Для этого можно выполнить команды

alter profile default limit sessions_per_user 1;

Затем создать профиль dba_profile и назначить его пользователю system

create profile dba_profile limit sessions_per_user unlimited password_life_time 7 password_grace_time 1;

alter user system profile dba_profile;

И создать профиль для программистов

create profile programmers_profile limit sessions_per_user 2;

alter user jon profile programmers_profile;

alter user sue profile programmers_profile;

Для вступления ограничений по ресурсам в силу необходимо установить параметр экземпляра

alter system set resource_limit=true;

Если экземпляр использует SPFILE это изменение применится к файлу параметров и будет использоваться даже после перезапуска.

Профиль нельзя удалить если он назначен какому-либо пользователю. Можно либо вначале перевести пользователей на другой профиль, либо использовать директиву CASCADE использование которой автоматически переназначит пользователей использующих удаляемый профиль назад на профиль DEFAULT.