W scyfryzowanym świecie kluczowe staje się umiejętne wykorzystanie narzędzi technologicznych w celu skutecznego zarządzania organizacją. W obliczu dynamicznego rozwoju technologii cyfrowych, firmy oraz przedsiębiorstwa decydują się na wprowadzanie innowacyjnych rozwiązań, które nie tylko usprawniają procesy operacyjne, ale również otwierają szereg nowych możliwości dostosowania się do zmieniających się warunków rynkowych.
Microsoft Power Platform stanowi jedno z czołowych narzędzi, które zdobyło uznanie w tym temacie. To zaawansowane środowisko umożliwia:
- automatyzację procesów biznesowych,
- tworzenie aplikacji,
- analizę danych.
Jednak, aby w pełni wykorzystać potencjał Power Platform, niezbędne jest zrozumienie jego strony administracyjnej.
W niniejszym artykule skupimy się na ważnych aspektach związanych z konfiguracją środowisk w ramach Power Platform; wspólnie zgłębimy krok po kroku etapy konfiguracji. Przyjrzymy się, dlaczego właściwa konfiguracja stanowi nieodzowny element skutecznego i bezpiecznego korzystania z Power Platform. Nie zabraknie również praktycznych wskazówek, które umożliwią wykorzystanie pełni potencjału administracyjnego platformy.
Pierwsze kroki na drodze konfiguracji
Każdorazowe przygotowanie nowego środowiska w ramach Power Platform powinno być poprzedzone staranną analizą. Dlatego przed przystąpieniem do tworzenia środowiska, warto pochylić się nad kilkoma pytaniami. Odpowiedzi będą miały wpływ na efektywność i dostosowanie konfiguracji do potrzeb naszej organizacji.
Wstępna analiza
- Cel i przeznaczenie środowiska: Czy planujemy utworzyć pojedyncze środowisko (np.: Center Of Excelence) dla administratorów i związane z tym zadania? Czy może potrzebujemy konfiguracji dostosowanej do wdrożeń o większej złożoności, potrafiącej obsłużyć rozbudowane aplikacje wspierane przez proces (ALM) (to rozwiązanie może wymagać utworzenia trzech oddzielnych środowisk: developerskiego, testowego i produkcyjnego)?
- Dostępność Dataverse Database Capacity[1]: Czy nasza organizacja posiada wystarczającą pojemność bazy danych Dataverse w swoim tenancie[2], aby utworzyć nowe środowisko?
- Zarządzanie dostępem: Czy chcemy, aby dostęp do środowiska był w pełni kontrolowany za pomocą Azure Active Directory/ Microsoft Entra ID[3], czy planujemy niezależne od siebie konfiguracje (w większości przypadków jednak chcemy, aby dostęp był zarządzany w jednym miejscu)?
- Zasady Data Loss Prevention: Czy w naszym środowisku wymagane jest zastosowanie zasad Data Loss Prevention[4], a jeśli tak, to jak mają one zostać skonfigurowane?
Scenariusz konfiguracyjny
Na potrzeby niniejszego artykułu przyjmiemy bardziej złożony scenariusz konfiguracyjny.
- Skupimy się na utworzeniu konfiguracji przyjaznej profesjonalnym wdrożeniom, obejmującej trzy oddzielne środowiska: developerskie, testowe i produkcyjne.
- Kontrola dostępu będzie się odbywać w ramach usługi Azure Active Directory/Microsoft Entra ID.
- Proces ALM będzie realizowany przy użyciu mechanizmu rozwiązań (Solutions[5]), w którym zmiany wprowadzać będziemy manualnie (istnieje opcja zautomatyzowania tego procesu, ale temat ten wykracza poza ramy tego artykułu).
Aby jeszcze lepiej zrozumieć wszystkie elementy składające się na tę konfigurację, przedstawię opisany scenariusz w formie diagramu:
Konfiguracja security group po stronie Microsoft Entra ID
Proces konfiguracji środowiska rozpoczniemy od odpowiedniego przygotowania Microsoft Entra oraz stworzenie odpowiednich Security Group. Ich synchronizacja pomiędzy Power Platform a Microsoft Entra pozwoli na zarządzanie dostępem do środowiska w pełni z poziomu Microsoft Entra.
- Zaczynamy od zalogowania się do Azure Portal. Wybieramy sekcję Azure Active Directory.
- Z uwagi na nadchodzące modyfikacje w obszarze Azure Active Directory, które obejmują przekształcenie w Microsoft Entra, wykonamy konfigurację w nowym interfejsie – Microsoft Entra Admin Center. Aby uzyskać do niej dostęp, należy przejść do sekcji Overview pod My Feed (ewentualnie możemy otworzyć poprzez bezpośredni adres URL: Home – Microsoft Entra admin center).
- Z menu po lewej stronie wybieramy: „Group” i „All Groups”.
- Klikamy przycisk: „New group”.
- Uzupełniamy szczegóły nowej grupy na Azure Portal. Oto przykładowa konfiguracja:
- Group type – Security,
- Group name – Security Group Power Platform Dev,
- Group description – Developer environment security group,
- Membership type – Assigned,
- Owners – wskazujemy osobę, która ma być właścicielem grupy,
- Members – wskazujemy osoby, które mają być członkami grupy. Po wykonaniu dalszej konfiguracji członkowie grupy uzyskają dostęp do środowiska (dostęp do środowiska nie oznacza dostępu do danych i operacji wykonywanych na środowisku; jest to osobna konfiguracja nieujęta w tym artykule).
- Kontynuujemy postępowanie zgodnie z etapami od 2 do 4, powtarzając te czynności, aż osiągniemy trzy odrębne grupy: Dev, Test oraz Production. W poniższej tabeli przedstawiam pełną przykładową konfigurację, którą można zastosować:
| Ustawienie | Dev Security Group | Test Security Group | Prod Security Group |
| Group type | Security | Security | Security |
| Group name | Security Group Power Platform Dev Environment | Security Group Power Platform Test Environment | Security Group Power Platform Prod Environment |
| Group description | Developer environment security group | Test environment security group | Production environment security group |
| Membership type | Assigned | Assigned | Assigned |
| Owners | Dowolny użytkownik zgodnie z polityką firmy | Dowolny użytkownik zgodnie z polityką firmy | Dowolny użytkownik zgodnie z polityką firmy |
| Members | Każdy użytkownik, który ma mieć dostęp do danego środowiska | Każdy użytkownik, który ma mieć dostęp do danego środowiska | Każdy użytkownik, który ma mieć dostęp do danego środowiska |
Teraz, dysponując odpowiednio skonfigurowanym Security Group, możemy przystąpić do konfiguracji środowisk w ramach Power Platform.
Konfiguracja środowisk po stronie Power Platform
Do zarządzania środowiskami w ramach Power Platform służy narzędzie Power Platform Admin Center. Chociaż Microsoft oferuje wiele metod, aby do niego przejść, najszybszym sposobem jest skorzystanie z bezpośredniego linku URL Power Platform admin center (microsoft.com).
Podczas pierwszego uruchomienia tego centrum administracyjnego, zobaczymy wiadomość powitalną oraz otrzymamy zaproszenie do krótkiej wirtualnej podróży zapoznawczej. Zachęcam do uczestnictwa w tej podróży, ponieważ pozwoli ona lepiej zrozumieć znaczenie i zastosowanie głównych elementów nawigacyjnych.
Nowe środowisko
Zakładam, że jesteśmy już po odbyciu wspomnianej wirtualnej podróży. W tym momencie możemy w pełni skupić się na tworzeniu nowego środowiska.
Pierwszym krokiem, który powinniśmy podjąć, jest upewnienie się, że mamy wystarczającą pojemność „Capacity Database” dla utworzenia nowego środowiska wraz z bazą danych Dataverse. Wymagane jest, abyśmy mieli co najmniej 1GB wolnej pamięci Database. W celu weryfikacji dostępnej pojemności, należy przejść do sekcji „Resources”, a następnie do podsekcji „Capacity”. Tam właśnie zostanie przedstawiony raport prezentujący wykorzystanie dostępnej pamięci.
W sytuacji, w której okaże się, że jednak nie mamy wystarczająco przestrzeni, istnieją dwie metody zaradcze:
- Zwolnienie przestrzeni w ramach aktualnych licencji. Możliwości oczyszczania bazy danych zostały szczegółowo opisane w oficjalnej dokumentacji Microsoft: Free up storage space – Power Platform | Microsoft Learn.
- Wykupienie licencji, która zwiększy „Database Capacity”. W większości przypadków będziemy musieli wybrać pomiędzy dokupieniem dedykowanej licencji „Dataverse Capacity Add On” a rozszerzeniem liczby licencji użytkowników. Aby dokonać właściwego wyboru, warto zapoznać się z przewodnikiem licencyjnym od Microsoft: Licensing overview for Microsoft Power Platform – Power Platform | Microsoft Learn.
Jednak w omawianej na łamach artykułu konfiguracji posiadamy wystarczającą przestrzeń do stworzenia nowego środowiska.
Następnym krokiem będzie przejście do sekcji Environment, gdzie będziemy mogli przystąpić do tworzenia środowiska poprzez naciśnięcie przycisku ‘+ New’.
Wówczas, po lewej stronie interfejsu, otworzy się nowe okno, w którym zaczniemy wprowadzanie parametrów środowiska.
Kreator tworzenia nowego środowiska składa się z dwóch etapów. Po zakończeniu wypełniania pierwszego okna i naciśnięciu przycisku „Save”, zostaniemy przeniesieni do drugiego okna.
Uwaga! Kliknięcie „Save” w pierwszym etapie, jeszcze nie prowadzi do utworzenia nowego środowiska. W poniższej tabeli szczegółowo przeanalizujemy każdy z punktów, które należy uzupełnić podczas tego procesu.
| Ustawienie | Opis | Czy można zmienić to ustawienie w przyszłości? |
| Name | Nazwa środowiska, która będzie zrozumiała dla użytkowników. Pełni istotną rolę, ponieważ będzie widoczna w różnych kontekstach zarówno dla administratorów, jak i dla osób pracujących nad tworzeniem aplikacji w tym środowisku. | Tak |
| Region | Region decyduje o tym, w jakich regionach Azure będą przechowywane zasoby związane ze środowiskiem. Warto zaznaczyć, że ustawienie to nie należy do precyzyjnych, ponieważ lokalizacja regionu Power Platform niekoniecznie pokrywa się z lokalizacją regionu Azure[6]. W rezultacie mogą pojawić się problemy związane z wbudowanymi integracjami z usługami Azure, takimi jak np.: Azure Synapse[7]. Aby określić region dla naszego wdrożenia, warto przejrzeć dostępne dokumentacje: Choose the region when setting up an environment – Power Platform | Microsoft Learn & Regions overview for Power Automate – Power Automate | Microsoft Learn | Tak – wymagane zgłoszenie biletu pomocy technicznej do Microsoft: Geo to geo migrations – Power Platform | Microsoft Learn |
| Type | Typ ma wpływ na różne procesy zachodzące w tle np.: ograniczenia dotyczące zasobów w środowisku. Dla przykładu środowiska developerskie nie zużywają Dataverse Capacity, ale posiadają pewne ograniczenia takie jak: liczba użytkowników, ilość zużywanej pamięci czy liczba uruchomień Power Automate[8]. Typ określa także czy środowisko wygaśnie po pewnym czasie (środowiska trial wygasają po upływie 30 dni[9]). | Nie zawsze. Możliwa jest zmiana typu środowiska zgodnie z ograniczeniami Microsoftu. Najpopularniejsze przypadki to: Sandbox -> Production Production -> Sandbox. Inne przypadki należy rozpatrywać zgodnie z dokumentacją Microsoft: Environments overview – Power Platform | Microsoft Learn |
| Purpose | Pole tekstowe, które umożliwia administratorom dodanie krótkiego opisu środowiska. | Tak |
| Add a Dataverse data store? | Ustawienie określa, czy chcemy utworzyć bazę Dataverse dla naszego środowiska. Zazwyczaj zdecydujemy się na jej dodanie. Informacje o sytuacjach, w których nie potrzebujemy bazy danych, można znaleźć w tym miejscu: Why create an environment without a database | Można dodać bazę danych w przyszłości. Jednak operacji nie można cofnąć, a jedynym sposobem na usunięcie bazy danych jest usunięcie całego środowiska. |
| Pay-as-you-go with Azure? | Ustawienie służy do określenia sposobu licencjonowania środowiska. Aktualnie mamy dwie opcje wyboru: Licencjonowanie zgodnie z aktualnymi licencjami organizacji – oznacza to, że organizacja musi posiadać zakupione wcześniej licencje, aby korzystać z konkretnych usług.Pay-As-You go – oznacza, że środowisko na bieżąco monitoruje swoje zużycie. Opłata za środowisko jest wystawiana na podstawie rzeczywistego zużycia. Więcej informacji na ten temat można zaleźć w tym miejscu: Pay-as-you-go plan overview – Power Platform | Microsoft Learn | Tak |
| Language | Określa domyślny język środowiska. Istnieje możliwość zainstalowania dodatkowych języków jak np.: polski, ukraiński, czeski, niemiecki, angielski i wiele innych wspieranych języków[10]. Języki dodatkowe możemy zainstalować w dowolnym momencie. Jednak język domyślny jest ustawiany tylko raz. Jest to istotne, ponieważ wpływa na: Ten język będzie ustawiony jako domyślny język dostosowań systemowych. Liczne elementy w systemie zależą od domyślnego języka (np. język interfejsu w starych panelach administracyjnych), może mieć to znaczenie w ramach pracy w międzynarodowym środowisku lub podczas współpracy z zespołem wsparcia Microsoft.Domyślny język będzie także domyślnym językiem dla użytkowników (użytkownicy otrzymają możliwość jego zmiany w ustawieniach personalnych[11]; zmiany dokonać będą mogli również administratorzy za pomocą narzędzia XRMToolBox User Settings Utility[12]). Mając na uwadze potrzeby wsparcia i rozwój systemu przez różnorodne zespoły i jednostki, rekomendowane jest ustawienie języka angielskiego jako języka domyślnego. Taka decyzja przyczynia się do ułatwienia uzyskiwania pomocy od zespołu wsparcia Microsoft, ale też eliminuje bariery językowe w trakcie procesu rozwoju systemu. Przykładowo, wybór języka angielskiego znacznie usprawni komunikację z partnerami Microsoft spoza Polski, co z kolei ułatwi i przyspieszy współpracę. | Nie |
| Currency | Definiuje walutę podstawową dla środowiska (base currency). System wspiera obsługę różnych walut i zawsze istnieje opcja dodania dodatkowych walut. Jednakże wybór waluty dokonany w tym miejscu staje się walutą podstawową (base currency). Co oznacza, że system będzie automatycznie przeliczał pola związane z walutą na walutę, którą ustawimy jako domyślną; także na walutę domyślną przy zastosowaniu określonego kursu walutowego[13]. Ze względu na tę automatyzację zazwyczaj stosuje się walutę podstawową do raportowania danych finansowych. Wybór waluty powinien być poprzedzony analizą innych raportów finansowych oraz potwierdzeniem od użytkowników biznesowych, jaką walutę można uznać za podstawową. | Nie |
| Security Group | Definiuje do której Security Group użytkownicy muszą zostać przypisani, aby otrzymać uprawnienia dostępu do środowiska[14]. | Tak |
| URL | Określa fragment adresu URL dotyczący środowiska, który stanowi część całego adresu URL. Przykładowy wzór pełnego adresu URL dla regionu europejskiego: https://[URL].crm4.dynamics.com/ W sytuacji, w której ustawimy adres URL na: ‘ContosoDev’ ostateczny adres URL będzie prezentował się następująco: ContosoDev.crm4.dynamics.com. Ponadto adres URL będzie ulegał zmianie w zależności od wybranego regionu[15]. | Tak |
| Enable Dynamics 365 Apps? | Definiuje czy w danym środowisku będzie możliwość zainstalowania aplikacji Dynamics 365. Odnotujmy, że na dzień 16.08.2023 istniała opcja aktywacji tej funkcji nawet w przypadku braku licencji na aplikacje Dynamics 365. Aby nie ograniczać sobie przyszłych możliwości lepiej włączyć tę opcję. | Nie |
| Automatically deploy these apps | Definiuje które aplikacje Dynamics 365 (w szczególności te z obszaru CRM/Customer Engagement) mają zostać dodane do środowiska Power Platform. Na tym etapie należy zakupić wcześniej odpowiednie licencje na konkretne aplikacje, aby móc je dodać. | Tak, możemy doinstalować aplikacje w każdym momencie. Pod warunkiem posiadania odpowiednich licencji. |
| Deploy sample apps and data? | Definiuje czy podczas tworzenia środowiska zostaną również wgrane przykładowe aplikacje i dane. Warto odnotować, że na dzień 16.08.2023 włączenie tej opcji powoduje doinstalowanietrzechaplikacji Model-Driven app. Więcej na ten temat można znaleźć: Model-driven sample apps – Power Apps | Microsoft Learn | Tak, możemy doinstalować te same aplikacje z poziomu make.powerapps.com bądź po utworzeniu środowiska zainstalować tylko same przykładowe dane: Add or remove sample data – Power Platform | Microsoft Learn |
Rozumiejąc konsekwencje związane z dokonanymi wyborami w powyższych opcjach środowiska, możemy przystąpić do spersonalizowanej konfiguracji własnych środowisk. Poniżej znajdują się parametry, które odnoszą się do naszych środowisk:
| Ustawienie | Środowisko Developerske | Środowisko Testowe | Środowisko Produkcyjne |
| Name | Power Platform Dev Environment | Power Platform Test Environment | Power Platform Prod Environment |
| Region | Europe | Europe | Europe |
| Type | Sandbox | Sandbox | Production |
| Purpose | Development environment for the purpose of discussing the process of creating environments and ALMs | Test/UAT environment for the purpose of discussing the process of creating environments and ALMs | Production environment for the purpose of discussing the process of creating environments and ALMs |
| Add a Dataverse data store? | Yes | Yes | Yes |
| Pay-as-you-go with Azure? | No | No | No |
| Language | English | English | English |
| Currency | PLN (zł) | PLN (zł) | PLN (zł) |
| Security Group | Security Group Power Platform Dev | Security Group Power Platform Test | Security Group Power Platform Prod |
| URL | Wprowadzamy własny unikalny adres URL lub pozwalamy na jego automatyczne wygenerowanie | Wprowadzamy własny unikalny adres URL lub pozwalamy na jego automatyczne wygenerowanie | Wprowadzamy własny unikalny adres URL lub pozwalamy na jego automatyczne wygenerowanie |
| Enable Dynamics 365 Apps? | Yes | Yes | Yes |
| Automatically deploy these apps | None | None | None |
| Deploy sample apps and data? | No (jeśli włączymy opcje “Enable Dynamics 365 Apps” to ta opcja zostanie ukryta) | No (jeśli włączymy opcje “Enable Dynamics 365 Apps” to ta opcja zostanie ukryta) | No (jeśli włączymy opcje “Enable Dynamics 365 Apps” to ta opcja zostanie ukryta) |
Finalna konfiguracja powinna prezentować się w następujący sposób:
Po ukończeniu konfiguracji, możemy rozpocząć pracę w naszych środowiskach. Należy mieć na uwadze, że dostęp do środowiska jest kontrolowany poprzez Security Group. Z tego wynika, że użytkownicy muszą zostać najpierw przypisani do odpowiednich grup, aby uzyskać dostęp do środowiska. Trzeba również pamiętać, że dostęp do środowiska nie oznacza automatycznie przyznania dostępu do aplikacji i danych na środowisku. Odpowiadają za to Security Roles, które można przypisać do poszczególnych użytkowników czy zespołów.
Podsumowanie i dalsze kroki
W artykule skupiliśmy się na procesie tworzenia środowisk. Warto zaznaczyć, że zakres działań administracyjnych jest znacznie szerszy niż opisana powyżej konfiguracja, jednak teraz zdobyliśmy solidne podstawy do dalszych działań. Nabierając wiedzy w kolejnych obszarach, będziemy w stanie efektywniej wykorzystywać możliwości konfiguracji, a także sprawniej zarządzać naszymi środowiskami. Zachęcam do samodzielnego poznawania dalszych kroków i możliwości wraz z dokumentacją Microsoft: Microsoft Power Platform admin documentation – Power Platform | Microsoft Learn
***
Jeśli interesuje Cię temat: Microsoft Entra – zintegrowany portal do zarządzania tożsamością, koniecznie zajrzyj do artykułu naszego eksperta.
[1] Omówienie Dataverse Database Capacity: New Microsoft Dataverse storage capacity – Power Platform | Microsoft Learn
[2] Definicja tenant: Define Azure Active Directory tenants – Cloud Adoption Framework | Microsoft Learn
[3] Ze względu na zmianę nazwy usługi z Azure Active Directory na Microsoft Entra w dalszej części artykułu będę używał nowszej nazwy – Microsoft Entra. Jednak na zrzutach ekranu może pojawiać się jeszcze nazwa Azure Active Directory Azure AD is Becoming Microsoft Entra ID – Microsoft Community Hub & New name for Azure Active Directory – Microsoft Entra | Microsoft Learn & Azure AD is being renamed to Microsoft Entra ID | Microsoft Entra Identity Developer Blog
[4] Omówienie Data Loss Prevention: Data loss prevention policies – Power Platform | Microsoft Learn
[5] Dokumentacja mechanizmu rozwiązań: Solutions in Power Apps – Power Apps | Microsoft Learn
[6] Aby to sprawdzić wystarczy porównać Regiony Azure Choose the Right Azure Region for You | Microsoft Azure z regionami Power Platform Regions overview for Power Automate – Power Automate | Microsoft Learn. W drugiej dokumentacji można dostrzec, że pod jeden region Power Platform przynależy kilka regionów Azure
[7] Problem wynika z sytuacji, w której w różnych regionach Azure są przechowywane zasoby dotyczące Power Platform, a w innych usługi dodatkowe. Np. Dokumentacja Azure Synapse link (Create an Azure Synapse Link for Dataverse with Azure Data Lake – Power Apps | Microsoft Learn) mówi że zasoby Power Platform i Synapse muszą być w tym samym regionie. Np. wybierając Power Platform w regionie Europejskim nasze zasoby mogą zostać wdrożone w North Europe lub West Europe (Na co nie mamy wpływu z poziomu Power Platform Admin Center). Przed rozpoczęciem takich prac należy sprawdzić w których Azure Region zostały wdrożone nasze środowiska Power Platform
[8] Omówienie środowisk developerskich: About the Power Apps Developer Plan – Power Platform | Microsoft Learn
[9] Omówienie środowisk trial: About trial environments: standard and subscription-based – Power Platform | Microsoft Learn
[10] Lista dostępnych standardowych języków jest dostępna tutaj: Microsoft Dataverse language collations – Power Platform | Microsoft Learn
[11] Dokumentacja ustawień personalnych: Set personal options – Power Apps | Microsoft Learn
[12] Link do narzędzia: User Settings Utility · XrmToolBox
[13] Więcej o systemie walut w Power Platform można przeczytać tutaj: Manage transactions with multiple currencies – Power Platform | Microsoft Learn & Transaction Currency (currency) table (Microsoft Dataverse) – Power Apps | Microsoft Learn
[14] Więcej o mechanizmie Security Group możemy przeczytać tutaj: Control user access to environments: security groups and licenses – Power Platform | Microsoft Learn
[15] Więcej informacji o zależności adres URL od regionu: Power Platform and Dynamics 365 datacenter regions – Power Platform | Microsoft Learn
Bardzo wartościowy artykuł. Na pewno do niego jeszcze raz wrócę.