Esse artigo faz parte de uma série recente de artigos que utilizam Windows em OCI integrado ao Active Directory.
Para Secure Desktops, você terá 2 modelos de artigo no Blog, e serão divididos da seguinte forma:
- OCI Secure Desktops – Como configurar para uso em OCI com join no Active Directory – Versão 1
- Nesse modelo você irá aprender a configurar todo o Windows Localmente, no VirtualBox, para quando você importar a imagem para OCI ela já esteja pronta para que você crie seu pool sem precisar de nenhuma ação adicional
- OCI Secure Desktops – Como configurar para uso em OCI com join no Active Directory – Versão 2
- Já nessa segunda versão, você vai preparar a imagem de forma simples, somente instalando os pacotes necessários para importar para OCI e em OCI fazer as ações para Active Directory, nesse modelo você pode por exemplo aprimorar sua imagem usando o Vault como Autenticação
Tá, mas qual a diferença entre os 2?
A diferença é que na Versão 1 você já envia a imagem pronta e toda a vez que você precisar fazer uma alteração na imagem o processo deverá ser realizado novamente por inteiro.
Já na Versão 2, você terá 1 imagem base em OCI, para que, quando você precisar por exemplo instalar uma nova aplicação no Windows 11, você consiga sempre fazer nessa base e depois recriar a versão para AD já em Oracle Cloud. Ou seja, você terá mais flexibilidade para o gerenciamento de imagens em OCI e poderá sempre ter versões mais rapidamente.
O objetivo é fazer com que você consiga, de uma forma prática realizar a configuração do Windows 10/11 para OCI e também tenha a possibilidade de usar o Adjoin quando as instâncias iniciarem.
Ponto Importante: Nesse artigo não vou usar o Vault para autenticar, mas se você já tiver toda sua infra preparada com o que temos por exemplo nesse artigo, você pode aprimorar o deploy mesclando as configurações.
Outro ponto muito importante, é que para que você consiga ter resoluções de nomes do seu domínio em OCI, tenha como referência já ter preparado sua infra em OCI conforme esse artigo.
A ultima consideração é que, para esse processo vamos utilizar o modelo de criação manual, ou seja, iremos preparar uma ISO no VirtualBox para posteriormente enviarmos para Oracle Cloud, porém você pode usar outros virtualizadores, desde que as extensões de arquivo sejam compatíveis com OCI
Iremos abordar esse artigo em passos, e será estruturado da seguinte forma:
- Passo 1: Preparando OCI para o Secure Desktop
- Passo 2: Preparando a máquina virtual no VirtualBox
- Passo 3: Preparando a instância para OCI (Instaladores)
- Passo 4: Preparando a instância para OCI (Scripts)
- Passo 5: Upload e configurações da imagem em Oracle Cloud
- Passo 6: Criação do Secure Desktop
- Passo 7: Acessando com o usuário final.
Antes de iniciar, é importante que leve em consideração todos os requisitos para criação de Imagem em Oracle Cloud
O tamanho máximo da imagem é de 400GB.A imagem deve estar configurada para um tipo de inicialização suportado:
- Para uma imagem do Windows 10, use o tipo de inicialização UEFI ou BIOS legado.
- Para uma imagem do Windows 11, use apenas o tipo de inicialização UEFI.
A imagem do disco não pode estar criptografada.A imagem do disco deve ser um arquivo VMDK ou QCOW2:
- Crie o arquivo de imagem clonando o volume de origem, e não criando um snapshot.
- Os arquivos VMDK devem ser do tipo “single growable” (monolithicSparse) ou “stream optimized” (streamOptimized), ambos consistindo em um único arquivo VMDK. Outros formatos de VMDK, como aqueles que usam múltiplos arquivos, volumes divididos ou contêm snapshots, não são suportados.
A interface de rede deve usar DHCP para descobrir as configurações de rede.
A configuração de rede não deve codificar manualmente o endereço MAC para a interface de rede.
Passo 1: Preparando OCI para o Secure Desktop
O serviço do Secure Desktop possui requisitos de configuração para funcionamento em Oracle Cloud.
Os requisitos são fundamentais e fazem parte do planejamento da melhor estratégia de arquitetura.
Abaixo vou listar os requisitos iniciais, e todos os principais pontos de atenção.
Compartimentos: Para o recurso do Secure Desktop é importante que você tenha em mente e planeje corretamente a segregação dos recursos baseados em grupos de usuários, e consequentemente Compartimentos.
Num exemplo prático e simples: imagine que você tenha 2 departamentos que irão usar imagens de Desktop diferentes, ou seja, terão aplicações diferentes para cada tipo de usuário.
A segregração dos acessos para usuários finais é realizada através de políticas, e elas são organizadas por compartimentos, abaixo temos um exemplo visual

Acima temos um exemplo de divisão lógica, para 2 grupos de Usuários (Financeiro e Tecnlogia) que possuem imagens base diferentes.
A segregação de acesso pelos Administradores do tenancy serão realizadas através do IAM e Políticas, criando as regras de Grupo para Compartimento, veremos mais a frente esse ponto.
Rede (Virtual Cloud Network): O Secure Desktop utiliza a rede (Virtual Cloud Network) da Oracle Cloud. A utilização é a mesma que é aplicada nos recursos de computação por exemplo.
No mínimo você deve ter 1 VCN, 1 Subnet Privada para que o serviço seja provisionado.
Não é necessário realizar liberações públicas ou portas específicas para o uso do Serviço, toda a tratativa de conexão é realizada através da camada de controle do serviço de forma segura e inteligente.
Políticas (Polices): As políticas para uso do serviço do Secure Desktop são organizadas em 3 principais pilares.
Políticas de Serviço: São políticas realizadas através do Dynamic Group, o serviço deve possuir permissões para conseguir realizar o provisionamento e gerenciamento de alguns serviços em Oracle Cloud
Para atingir esse objetivo, crie as seguintes políticas em OCI, respeitando o exemplo abaixo:
Crie um Dynamic Group e adicione uma das seguintes regras:
Uma matching rule para identificar o recurso do Desktop Pool
resource.type = 'desktoppool'
Opcionalmente você pode adicionar uma política para identificar os compartimentos que contem os Desktop Pools
Any {resource.compartment.id = '<ocid>', resource.compartment.id = '<ocid>’}
Após configurar o Dynamic Group, vá até o compartimento root e crie a seguinte política para o Dynamic Group
Allow dynamic-group <dynamic-group> to {DOMAIN_INSPECT} in tenancy
Allow dynamic-group <dynamic-group> to inspect users in tenancy
Allow dynamic-group <dynamic-group> to inspect compartments in tenancy
Allow dynamic-group <dynamic-group> to use tag-namespaces in tenancy
No compartimento root ou nos compartimentos de cada recurso, crie as regras adicionais para garantir que o Serviço consiga executar todas as tarefas de gestão dos recursos
Allow dynamic-group <dynamic-group> to use virtual-network-family in compartment <desktop -network-compartment>
Allow dynamic-group <dynamic-group> to {VCN_ATTACH, VCN_DETACH} in compartment <desktop -network-compartment>
Allow dynamic-group <dynamic-group> to manage virtual-network-family in compartment <desktop-compartment>
Allow dynamic-group <dynamic-group> to read instance-images in compartment <image-compartment>
Allow dynamic-group <dynamic-group> to manage instance-family in compartment <desktop-compartment>
Allow dynamic-group <dynamic-group> to manage volume-family in compartment <desktop-compartment>
Allow dynamic-group <dynamic-group> to manage dedicated-vm-hosts in compartment <desktop-compartment>
Allow dynamic-group <dynamic-group> to manage orm-family in compartment <desktop-compartment>
Allow dynamic-group <dynamic-group> to {VNIC_CREATE, VNIC_DELETE} in compartment <desktop-compartment>
Allow dynamic-group <dynamic-group> to manage instance-configurations in compartment <desktop-compartment>
Onde:
<ocid> = é o ocid dos compartimentos que irão ser provisionados os Desktop Pools
<dynamic-group> = é o nome do Dynamic Group que você criou para o serviço
<desktop -network-compartment> = é o compartimento que você criou a VCN para o Serviço
<image-compartment> = compartimento que você irá enviar e salvar a imagem do Secure Desktop
<desktop-compartment> = será o compartimento que os recursos serão provisionados:
Lembre-se: Se você for segregar compartimentos para grupos de usuário, garanta que a política seja herdada ou esteja corretamente criada para que o serviço funcione normalmente
Passo 2: Preparando a máquina virtual no VirtualBox
Com a Oracle Cloud preprada, vamos agora partir para a segunda etapa.
Irei utilizar o VirtualBox para preparar minha instância, isso será feito de forma manual. Você pode utilizar outros virtualizadores de sua preferência. Não testei todos, mas a premissa principal é que você faça os passos que estão descritos abaixo, seguindo todas as recomendações.
Para o artigo, vou utilizar a versão mais atualizada do Windows 11, atualmente estamos na versão 24H2.
Nem todas as etapas de configuração do recurso no VirtualBox serão apresentadas, somente irei mostrar as principais e que podem impactar de alguma forma negativamente no provisionamento do recurso.
Se precisar, faça o download da imagem do Windows 11
Ao abrir o VirtualBox, defina as configurações inicias como Nome, Imagem, localização da instância
No meu caso, irei pular a Instalação desassistida e irei prosseguir com a instalação manual

Na parte de hardware, irei definir a configuração para que eu possa conseguir instalar localmente

Em disco, temos considerações importantes
- Defina o caminho do disco, lembre-se desse caminho, você irá usar depois para fazer o upload para OCI
- Defina o tamanho do Sistema Operacional em GB, é importante ressaltar, conforme requisitos no início do artigo que não ultrapasse o tamanho máximo de 400GB
- Em formado de imagem, defina VMDK ou QCOW2, outros formatos também não fazem parte dos requisitos.

Após clicar em iniciar eu irei fazer uma última alteração, para evitar erros no Sysprep, irei em Configurações > Sistema e irei desativar a opção Secure Boot.

Após isso, faça a instalação do Sistema Operacional, e algumas dicas que gosto de deixar nessa etapa:
- Instale as atualizações de segurança e aplicativos mais recentes.
- Habilite o firewall e configure-o para permitir apenas as regras necessárias.
- Desative contas privilegiadas desnecessárias.
- Use senhas fortes para todas as contas.
- Configure seu servidor de ativação de licença:
slmgr.vbs /skms <KMS_server_name_or_IP>:1688
- Se a máquina virtual (VM) tiver armazenamento conectado remotamente, como NFS ou volumes de blocos, configure os serviços que dependem desse armazenamento para iniciar manualmente.
- Certifique-se de que todas as interfaces de rede usem DHCP e de que os endereços MAC e IP não sejam configurados manualmente.
Dica: Se você quiser configurar uma conta local durante a instalação, desative a interface de rede e quando chegar na tela de configuração de conta, digite Shift + F10 e no CMD o seguinte comando: oobe\bypassnro
Ao reiniciar ele vai habilitar a opção de escolher o provisionamento sem internet e irá permitir a criação de uma conta local.
Passo 3: Preparando a instância para OCI (Instaladores)
Após finalizar a configuração do Windows 11, vamos realizar os procedimentos de instalação e scripts para Oracle Cloud.
O primeiro passo é instalar 3 aplicativos que são de extrema importância para funcionamento em Oracle Cloud.
- Cloudbase-Init: Essa aplicação é responsável por realizar a execução de scripts de inicialização. No nosso cenário iremos utilizar ela para execução do script .bat que será responsável por fazer o processo de Join no Active Directory
- Oracle Cloud VirtIO Drivers: Os drivers de virtualização para Microsoft Windows são peça fundamental para funcionamento da nossa instância em Oracle Cloud.
- Oracle Cloud Agent: O Oracle Cloud Agent é um processo leve que gerencia plug-ins em execução nas instâncias de computação. Os plug-ins coletam métricas de desempenho, instalam atualizações do sistema operacional e executam outras tarefas de gerenciamento de instâncias. O processo de download do agente deve ser realizado através de uma requisição via Suporte
Vou iniciar o processo pela instalação do Oracle Cloud Agent.
A instalação dele é Next > Next > Finish, nada demais. Siga todos as etapas de instalação padrão.

Depois iremos instalar o Cloudbase-Init. Aqui temos que ter atenção ao procedimento durante a instalação devido a algumas mudanças.
Quando chegar na etapa de configuração, ele provavelmente irá estar informando a conta “Admin”, se você estiver usando o Windows em Portugues por exemplo, altere para Administrador, se for ingles Administrador.
Não marque a opção de executar com a conta Local System

Deixe as opções desmarcadas e clique em Finish

Agora iremos para a última etapa dos instaladores, iremos instalar o VirtIO.
Ele também é simples, Next > Next > Next, ao final da instalação você pode reiniciar o seu Windows 11.

Com isso terminamos o Passo 3.
Passo 4: Preparando a instância para OCI (Scripts)
Agora vamos realizar alguns ajustes na instância para que ela fique pronta para enviar para Oracle Cloud.
Para seguir na etapa eu compilei todos os requisitos que estão presentes na documentação oficial da Oracle e fiz uma pequena automação para auxiliar no processo.
Faça download dos arquivos presentes nesse link e extraia diretamente para a unidade C:\ da máquina Windows 11, ele deverá ficar da seguinte forma: C:\OCI-SD

Vou explicar um pouco o que contém na pasta e como ela atua.
Você pode ver na imagem acima que você tem um arquivo Read-Me, que basicamente tem todos os passos para executar e informações de como realizar a configuração.
Dentro da pasta Scripts você terá 1 arquivo chamado Automacao-Secure-Desktops.ps1 , que será responsável por realizar uma série de tarefas de forma automática para auxiliar no processo, vou explicar com mais detalhes abaixo. Também verá uma outra pasta chamada Arquivos
Dentro da pasta Arquivos você terá arquivos que serão movimentados de forma automática para os diretórios que precisam estar.

- domainjoin.ps1:
- Arquivo de configuração para inserção automática no domínio.
- Esse arquivo quando o script Automacao-Secure-Desktops.ps1 for executado irá ser movimentado para o diretório c:\temp do Windows Desktop
- Você deve realizar alterações nele antes de realizar o Sysprep com os dados do seu domínio, no arquivo Read-Me.txt tem as informações e campos que devem ser alterados para auxiliar.
- script.bat
- Esse script irá ser movido também para a pasta do CloudInit, C:\Program Files\Cloudbase Solutions\Cloudbase-Init\LocalScripts\ e terá como função executar o arquivo domainjoin.ps1, quando ele terminar de executar irá realizar a deleção do arquivo e por fim reiniciar a instância
- unattend.xml
- Arquivo de configuração simples para execução do Sysprep, ele será enviado para o diretório do usuário atual C:\Users\<seu-usuario>\AppData\Local\Temp
- Se tiver algum arquivo de configuração que goste de utilizar, você pode colar sobre esse arquivo na pasta antes de executar o script de automação do processo.
- VFX.ps1
- Esse script tem como objetivo otimizar os efeitos visuais no Windows para melhorar o desempenho.
- Ele será copiado automaticamente para o caminho: C:\VDI-Scripts, será executado automaticamente toda vez que o sistema iniciar para garantir que as configurações sigam o recomendao.
Bom, agora preciso explicar para vocês o script Automacao-Secure-Desktops.ps1, ele está totalmente comentado, ou seja, cada bloco de execução tem sua explicação, mas basicamente ele faz o seguinte:
- Desativa o Firewall do Windows
- Habilita a bypass para verificações de requisitos mínimos de hardware (RAM, Secure Boot e TPM)
- Ajusta as permissões para execução de Scripts no Powershell
- Desabilita LockScreen
- Adiciona exceções no Firewall para as principais portas do Active Directory
- Adiciona uma linha ao arquivo C:\Program Files\Cloudbase Solutions\Cloudbase-Init\conf\cloudbase-init.conf para aumentar a quantidade de tentativas de execução de scripts
- Copia o arquivo VFX.ps1 de “C:\OCI-SD\Scripts\Arquivos\VFX.ps1” para “C:\VDI-Scripts\”, depois executa a configuração no regedit
- Copia o script domainjoin.ps1 de “C:\OCI-SD\Scripts\Arquivos\domainjoin.ps1” para “C:\temp\”
- Copia o arquivo unattend.xml de “C:\OCI-SD\Scripts\Arquivos\unattend.xml” para “$Env:TEMP\”
- Por fim, exibe um Pop-Up dizendo que você deve alterar os dados no arquivo domainjoin.ps1 e executar o comando para sysprep.
Bom, explicado, vamos agora executar.
Eu recomendo primeiro fazer a alteração no arquivo domainjoin.ps1, com os seus dados de domínio, para evitar esquecer.
Para isso navegue até C:\OCI-SD\Scripts\Arquivos e edite o arquivo domainjoin.ps1
Altere as linhas:

Salve o arquivo na mesma pasta que ele está.
Feito isso, abra o Powershell como Administrador e execute o seguinte comando:
PowerShell.exe -ExecutionPolicy Bypass -File C:\OCI-SD\Scripts\Automacao-Secure-Desktops.ps1

Agora, ainda com o Powershell como Administrador, navegue até o diretório do script e execute o mesmo

O script irá fazer todas as alterações necessárias e por fim irá apresentar a mensagem para validar o arquivo domainjoin.ps1 e orientação para executar o Sysprep.

Valide se todas as configurações foram aplicadas
- domainjoin.ps1 no diretório C:\temp com suas informações de domínio inseridas
- VFX.ps1 no diretório C:\VDI-Scripts
- retry_count=100 adicionado ao arquivo: C:\Program Files\Cloudbase Solutions\Cloudbase-Init\conf\cloudbase-init.conf
- Arquivo unattend.xml para o diretório C:\Users\<seu-usuario>\AppData\Local\Temp
Executei esse processo algumas vezes e sempre foram copiados da forma correta, mas recomendo validar para garantir.
Depois de validar, ainda com o Powershell como Administrador, saia do Diretório e execute o seguinte comando para deletar a pasta OCI-SD, não iremos mais utilizar
Remove-Item -Path "C:\OCI-SD" -Recurse -Force
Por fim, rode o Sysprep
C:\Windows\System32\Sysprep\sysprep.exe /oobe /generalize /shutdown /unattend:$Env:TEMP\unattend.xml

A máquina irá desligar, garanta que ela também esteja desligada no seu virtualizador local antes de ir para a próxima etapa
Passo 5: Upload e configurações da imagem em Oracle Cloud
Agora chegamos na hora de realizar o Upload da imagem para OCI.
Você pode fazer de duas formas:
1 – Usando o Oracle CLI com o comando abaixo:
oci --profile <profile in $HOME/.oci/config> --region <region> os object put\
-bn <name of bucket> \
-ns <name space> \
--name <The name of the object in the bucket> \
--file <path to the QCOW2 or VMDK image>
2 – Realizar manualmente, via console.

Após terminar o upload, você deve converter essa imagem para o formato rdaasw, você pode fazer isso de 2 formas tambem, direto de uma máquina que tenha Oracle CLI, executando o seguinte comando:
oci --profile <profile in $HOME/.oci/config> --region <region> \
compute image import from-object \
-ns <name space> \
-bn <name of bucket> \
--name <The name of the object in the bucket> \
--compartment-id <The OCID of the compartment you want the custom image to be created in> \
--display-name <A user-friendly name for the new custom image> \
--operating-system rdaasw \
--operating-system-version <Windows10 or Windows11> \
--launch-mode PARAVIRTUALIZED \
--source-image-type QCOW2|VMDK
Ou se preferir usar o próprio CloudShell do console para realizar a conversão
oci compute image import from-object \
-ns <name space> \
-bn <name of bucket> \
--name <The name of the object in the bucket> \
--compartment-id <The OCID of the compartment you want the custom image to be created in> \
--display-name <A user-friendly name for the new custom image> \
--operating-system rdaasw \
--operating-system-version <Windows10 or Windows11> \
--launch-mode PARAVIRTUALIZED \
--source-image-type QCOW2|VMDK
Altere os dados com as informações pertinentes e relacionadas ao seu ambiente.
Depois que terminar de converter a Custom Image, a primeira coisa que devemos fazer é alterar e definir tags para que o serviço consiga utilizar a imagem.
Eu não vou detalhar todas as tags pois existem casos de uso e particularidades, aqui vou abordar só as que podem ter impactos negativos. Você pode acessar a documentação completa de tags nesse link
Para nosso exemplo, vou usar as seguintes tags:
Chave de Tag | Valor da Tag | Descrição |
---|---|---|
oci:desktops:is_desktop_image | true | Permite que a imagem seja usada por Secure Desktops para provisionar desktops. Esta tag é obrigatória. |
oci:desktops:image_os_type | Windows | Especifica o tipo de sistema operacional da imagem. Esta tag é obrigatória. |
oci:desktops:image_version | <versao> | Especifica uma referência <version> de imagem significativa. Esta tag é opcional. |
oci:desktops:use_dedicated_host | false | Desativa o provisionamento DVH padrão para desktops do Windows 10/11. Esta é uma opção se o seu contrato de licença permitir a virtualização de desktops Windows 10/11 em um ambiente de nuvem. Esta tag é obrigatória. |
oci:desktops:is_auth | true | Desativa o provisionamento automático da conta de usuário da área de trabalho padrão. Em vez disso, adie para o esquema de agem. No nosso caso, por estar usando autenticação com AD é obrigatória. |
Ponto extremamente importante! A tag oci:desktops:use_dedicated_host
, deve ser muito bem avaliada antes de optar por não ou utilizar ela, tanto para a capacidade computacional quanto o contrato de licença Microsoft. Veja essa documentação de apoio para melhor entendimento

Para finalizar, vamos editar a imagem para garantir que ela esteja com as configurações ideais.
Baseado nos requisitos:
- Para uma imagem do Windows 10, use o tipo de inicialização UEFI ou BIOS legado.
- Para uma imagem do Windows 11, use apenas o tipo de inicialização UEFI.
Na Custom Image vá na opção Edit Image Capabilities

Mesmo que esteja na opção correta, salve a imagem novamente, caso não esteja, edite e salve

Dica adicional:
Edite também os detalhes da instância para que somente os shapes permitidos apareçam na lista de provisionamento

Passo 6: Criação do Secure Desktop
Chegamos na etapa de configuração do Secure Desktop
Para atingir o objetivo é importante que as Politicas de Serviço e para usuário Administrativo estejam configuradas previamente
Entendendo que estão ok, irei mostrar abaixo, de forma detalhada cada campo na configuração do Secure Desktop, separado por blocos.

1 – Name: Defina um nome para o Secure Desktop, esse nome será também visível para os usuários finais
2 – Description: Defina uma descrição, esse campo é opcional
3 – Pool Start Time: é um agendamento que pode ser definido para executar somente 1 vez, até o momento da execução o Pool ficará inativo.
4 – Pool Stop Time: também é um agendamento que pode ser definido para executar somente 1 vez e ao atingir o tempo definido o Pool ficará inativo
5 – Administrator contact details: Você pode opcionalmente definir um texto ou informações de contato Administrativa, essas informações ficam disponíveis para os usuários finais na interface de acesso ao Secure Desktop
6 – Administrator privileges: Você pode habilitar ou desabilitar privilégios administrativos para os usuários finais em seus Desktops

7 – Maximum size: Nesse campo você define o tamanho máximo que o Pool pode atingir, esse valor tem como número mínimo de 10 e máximo de 240 até o presente momento. O valor informado nesse campo será o valor por Desktop que o serviço irá cobrar. É importante ressaltar que o Secure Desktop tem cobranças de SKU de Serviço e SKUs de Computação, os recursos computacionais só serão cobrados se os usuários acessarem os computadores ou se você definir um valor no Standby size, por padrão os recursos são provisionados sob demanda
8 – Standby size está relacionado a quantidade de instâncias que você quer que fique em espera. Esse ponto é importante, por exemplo se as execuções de scripts demorarem muito para iniciar a instância. Como recomendação, deixe recursos em Standby criados para garantir a agilidade. Se você agregar o conceito de hibernação que será apresentado posteriormente, as instâncias em Standby também ficarão desligadas reduzindo custos de computação.
9 – Placement: Algumas regiões possuem mais de 1 AD, se for seu caso, você pode selecionar o Ad que o recurso será provisionado

10 – Desktop image: As imagens que forem aplicadas as tags oci:desktops:is_desktop_image
ficarão disponíveis para selecionar nesse campo. Somente imagens com essa tag ficam disponíveis.
11 – Use dedicated virtual machine host: Esse caso de uso é voltado para cenários que você não pode utilizar seu licenciamento BYOL de Desktop em OCI, para isso é necessário provisionar um host dedicado, essa opção deve ser selecionada
12 – Desktop virtual machine shape type: Os modelos de shapes flexíveis e fixos podem ser modificados nessa opção
13 – Desktop shape: Os shapes compatíveis com a imagem e modelo de provisionamento (Host Dedicado ou On Demand) aparecerão nesse campo.
14 – Desktop system resource configuration: Se você utilizar o Dedicated Virtual Machine Host somente shapes fixos poderão ser selecionados, se você utilizar os shapes On-Demand, poderá utilizar os Shapes flexíveis para definir shapes fixos ou até mesmo customizar a quantidade de oCPU, Memória e utilização de Burstable para cada Desktop

15 – Enable desktop storage: Você pode habilitar um disco secundário para as instâncias que serão anexadas como a Unidade D:. Esse disco é persistente ao usuário e não compartilhado.
16 – Desktop storage volume size (GB): Você pode definir um tamanho de 50GB até 10000GB.
17 – Backup policy: Também é possível atrelar uma política de backup para cada disco no momento do provisionamento.

18 – Virtual Cloud Network: Defina uma VCN para o Secure Desktop. As instâncias utilizam a rede padrão da Oracle Cloud.
19 – Subnet: Defina uma subnet, a subnet não precisa ser pública, o serviço não expoe as instâncias publicamente nem regras de entrada para RDP por exemplo precisam ser configuradas. Todo acesso é realizado através da camada de serviço.
20 – Use network security groups to control traffic: Adicionalmente você pode criar e adicionar NSGs para serem atrelados a cada instância do Pool para controle de entrada ou saída.

21 – Private endpoint access only: Se essa opção estiver desativada, os acessos aos desktops serão realizadas de forma segura mas irão utilizar o acesso via internet. Se você ativar esse recurso, você define que os acessos, após a autenticação só poderão ser realizados através de link privado. Para utilizar o acesso via link privado você precisa ter conectividade privada com a rede que será definida abaixo via VPN ou FastConnect e também conseguir resolver o endereço privado de DNS que o serviço irá prover.
22 – Virtual Cloud Network: Defina uma VCN para o Secure Desktop. As instâncias utilizam a rede padrão da Oracle Cloud.
23 – Subnet: Defina uma subnet, a subnet não precisa ser pública, o serviço não expoe as instâncias publicamente nem regras de entrada para RDP por exemplo precisam ser configuradas. Todo acesso é realizado através da camada de serviço.
24 – IP address for private endpoint: Você pode definir um endereço de IP válido para o private endpoint ou deixar ele gerar o próximo disponível na rede. Importante para resolução de DNS e liberação de acesso também.

25 – Clipboard access: Os administradores podem definir as regras de copiar e colar entre Full, A Partir do Destkop ou a Partir da Origem ou nenhuma permissão
26 – Audio access: Só funciona no modo Client, e pode ser definido como Acesso total, somente microfone, somente áudio ou nenhuma permissão
27 – Drive mapping access: Só funciona no modo Cliente, e pode ser definido como Leitura/Escrita, somente leitura ou nenhuma permissão

28 – Action on Inactivity e Grace periodo for inactivity (in minutes): Se você selecionar a opção Disconect em Action você deve definir um período de inatividade que o usuário será desconectado da instância. Usuário ocioso sem movimentação de mouse, teclado ou interação, se ativado é desconectado.
29 – Action on disconnect e Grace period for disconnect (in minutes): Selecionando a ação quando o usuário for desconectado para Stop por exemplo, você terá que definir um tempo que isso irá ocorrer. Antes de dar o “Stop” no recurso, a sessão do usuário é salva em disco e reestabelecida quando o usuário acessar novamente.
30 e 31 – Ações de Start e Stop: Você pode definir uma agenda regular para que todas as máquinas do Pool sejam ligadas e desligadas, baseado em agendamento.
Ponto adicional: As ações de acitivade para Hibernação tem influencia também nas instâncias de Standby, ou seja, se ativado elas também são pausadas. Quando um recurso em OCI é pausado, a cobrança de oCPU e Memória também é parada, somente o disco é cobrado.
Se a instância for desligada pelo serviço, quando o usuário clicar no link para acesso ela será religada imediatamente e liberada para o usuário.
Passo 7: Acessando com o usuário final.
Com o recurso provisionado, envie a url de acesso para os usuários finais, ela é formada da seguinte forma:
https://published.desktops.<region>.oci.oraclecloud.com/client
Onde <region> é a região de provisionamento, exemplo par Ashburn:
https://published.desktops.us-ashburn-1.oci.oraclecloud.com/client
Eles irão ter que autenticar no Domains da Oracle Cloud, e após autenticarem os Desktops que eles tiverem permissão serão apresentados, ele clicando no Link o desktop será acionado.
Se a instância tiver desligada devido a hibernação, ela será religada ao clicar no botão.
Se não existir ainda um Desktop para o usuário, no momento do clique no link um desktop será criado/assinado para o usuário.

Ele pode definir as preferências de acesso

E realizar download dos Clientes dependendo do seu Sistema Operacional
Abaixo um exemplo do acesso ao clicar no recurso que está atrelado a meu Active Directory, primeiro ele pede a senha e depois libera o desktop. As credenciais de acesso nessa segunda etapa devem ser do domínio
Modo web:

Modo Client


O desktop é persistente ao usuário, ou seja, sempre que realizar o acesso o usuário terá a mesma máquina de trabalho.
Bom pessoal, é isso, espero que esse artigo possa auxiliar vocês no provisionamento do recurso usando a integração com o Active Directory.
Qualquer dúvida estou a disposição.
Obrigado.