Pokazywanie postów oznaczonych etykietą Sharepoint. Pokaż wszystkie posty
Pokazywanie postów oznaczonych etykietą Sharepoint. Pokaż wszystkie posty

03 czerwca 2020

Zmiana domyślnej ścieżki dla witryn Teams

Jednym z pytań, które co jakiś czas do mnie powraca, jest możliwość zmiany domyślnej ścieżki (tzw. Managed Path) dla kolekcji witryn związanej z zespołami Teams. Dla małej firmy lub szkoły, gdzie użycie witryn intranetowych Sharepoint jest niewielkie, raczej nie ma to znaczenia, ale już gdy mamy co najmniej kilkadziesiąt zespołów i podobną ilość witryn komunikacyjnych, którymi na dodatek zarządzają różne zespoły, temat zaczyna być istotny. Jeżeli tworzymy nową witrynę komunikacyjną w Sharepoint Online, możemy wybrać ścieżkę Managed Path /sites/ lub /teams/ jak widać na poniższym obrazku.


















Jednak gdy tworzymy witrynę zespołu, lub tworzymy zespół bezpośrednio w Teams (w tle tworzy się wtedy odpowiednia witryna Sharepoint typu zespół), to nie ma takiej możliwości (kolejny obrazek).




















Jak zatem rozdzielić witryny tak, żeby witryny zespołowe automatycznie tworzone były w ścieżce Managed Path /teams/? Gdy kolejny raz pytanie do mnie wróciło w zeszłym tygodniu, okazało się że w ustawieniach Sharepointa Online pojawiła się opcja wyboru tej ścieżki. Po ustawieniu wartości domyślnej, wszystkie witryny zespołowe będą tworzone zgodnie z naszymi oczekiwaniami.


13 kwietnia 2020

Zmiana nazwy zespołu w Teams

Jednym z ciekawszych pytań, jakie ostatnio dostałem, była kwestia zmiany zespołu w Microsoft Teams. Rozwiązanie wydaje się trywialne i co więcej, może być potrzebne każdemu administratorowi prędzej, czy później. Na pozór stosunkowo proste  - wejść we właściwości zespołu, wybrać opcję edycji zespołu i zmienić (zarówno w kliencie desktopowym jak i webowym), jak widać na kolejnych rysunkach:





















Pozornie problem mamy rozwiązany. Jednak jeżeli wejdziemy w listę plików danego zespołu, a zwłaszcza gdy będziemy chcieli otworzyć taką listę w aplikacji Sharepoint, bądź też zerkniemy w konsoli administracyjnej na adres mailowy zespołu, to zauważymy, że zarówno url witryny sharepointowej naszego zespołu jak i email pozostały bez zmian. Co powinniśmy zrobić, żeby mieć spójną konfigurację? Na szczęście od kilku miesięcy możliwa jest zmiana adresu witryny Sharepoint.
W tym celu możemy użyć konsoli administracyjnej Sharepoint i zmienić zarówno nazwę jak i adres URL witryny zespołu (kolejny rysunek).
















Oczywiście operacja taka trwa dość długo (w tym czasie witryna jest dostępna w trybie tylko do odczytu). Niestety mogą się również pojawić inne problemy, o czym Microsoft pisze w dokumentacji, więc jeżeli mamy jakieś dokumenty, to warto je sobie zabezpieczyć. Operację zmiany adresu witryny możemy wykonać również z powershella, używając modułu Sharepoint Online, a dokładniej komendy Start-SPOSiteRename, jednak nie będę wchodził w szczegóły, zainteresowanych odsyłam do artykułu Tony'ego Redmonda.
Kolejną operacją jest modyfikacja adresu mailowego, co najlepiej jest wykonać z powershella. Żeby było trudniej, musimy do tego użyć innego modułu - Exchange Online, ponieważ zmieniamy atrybut grupy Office 365 (w module MicrosoftTeams nadal nie ma nawet możliwości podejrzenia adresu pocztowego). Komendą get-unifiedgroup możemy zweryfikować wartości atrybutów zespołu, a poprzez set-unifiedgroup ustawiamy odpowiednią wartość. W ten sposób mamy ujednolicone wartości nazwy zespołu po zmianie dla wszystkich elementów konfiguracji.



















Pozostaje jeszcze jeden drobiazg - notes zespołu, bądź też w przypadku zespołów klasowych, kwestia dotyczy notesu klasowego. On też ma nazwę powiązaną w momencie tworzenia z nazwą zespołu, więc żeby spójność była pełna to również i tą nazwę powinniśmy zmienić. W tym przypadku kwestia nie była taka oczywista, jednak udało mi się zweryfikować, że jest to możliwe. Podobnie jak w przypadku zmiany adresu url, w tym wypadku także użyjemy portalu administracyjnego Sharepoint, a właściwie właściwości witryny Sharepoint naszego zespołu.
Otwieramy w przeglądarce witrynę naszego zespołu, wchodzimy w zawartość witryny, następnie otwieramy Zawartość Witryny-Elementy zawartości Witryny i następnie edytujemy Nazwę i Tytuł notesu: 

























I to wszystko co potrzebujemy. 
Jak widać zmiana nazwy zespołu jest dosyć pracochłonna, więc warto dobrze przemyśleć nazewnictwo, żeby nie zmieniać nazw zbyt często.

02 grudnia 2018

Przykłady dostosowywania TeamSites

Tydzień temu miałem przyjemność prowadzić prezentację na konferencji Sharecon 2018, dotyczącą automatyzacji zadań związanych z tworzeniem TeamSite'ów. Ostatnio trochę głębiej badałem ten temat w związku z projektami wdrażania Microsoft Teams (a przecież TeamSite na Sharepoincie Online jest tworzony dla każdego zespołu Teams). Prezentację uzupełniłem o przykłady wykorzystania powershella i stwierdziłem, że warto o tym parę słów napisać.
Pierwszy przykład, wykorzystujący Powershella związany był z zagadnieniem Sharepoint Site Theming. Możemy w prosty sposób utworzyć i zastosować własny temat kolorystyczny (skrypt yellowtheme.ps1), który  następnie możemy użyć do utworzenia sitescriptu, wykorzystanego następnie do zmiany domyślnego szablonu strony TeamSite.
#
# yellowtheme.ps1
#

Connect-PnPOnline -Url https://pepugnet-admin.sharepoint.com
$themepalette = @{
    "themePrimary" = "#ffdd00";
    "themeLighterAlt" = "#fffded";
    "themeLighter" = "#fff9d1";
    "themeLight" = "#fff090";
    "themeTertiary" = "#ffe53f";
    "themeSecondary" = "#ffde0b";
    "themeDarkAlt" = "#e6c700";
    "themeDark" = "#a38d00";
    "themeDarker" = "#8c7a00";
    "neutralLighterAlt" = "#f8f8f8";
    "neutralLighter" = "#f4f4f4";
    "neutralLight" = "#eaeaea";
    "neutralQuaternaryAlt" = "#dadada";
    "neutralQuaternary" = "#d0d0d0";
    "neutralTertiaryAlt" = "#c8c8c8";
    "neutralTertiary" = "#595959";
    "neutralSecondary" = "#373737";
    "neutralPrimaryAlt" = "#2f2f2f";
    "neutralPrimary" = "#000000";
    "neutralDark" = "#151515";
    "black" = "#0b0b0b";
    "white" = "#ffffff";
    "primaryBackground" = "#ffffff";
    "primaryText" = "#000000";
    "bodyBackground" = "#ffffff";
    "bodyText" = "#000000";
    "disabledBackground" = "#f4f4f4";
    "disabledText" = "#c8c8c8";
}

Add-PnPTenantTheme -Identity "yellowTheme" -Palette $themepalette -IsInverted $false

Powyższy skrypt działa bardzo prosto - łączymy się do naszego tenanta O365, a konkretnie do witryny administracyjnej SPO (w przykładzie używam swojego tenanta testowego). Następnie definiujemy paletę kolorystyczną naszego tematu - brzmi groźnie, jednak na stronie Theme Generator Tool jest dostępny online'owy edytor kolorów, który generuje nam od razu odpowiednią tablicę w Powershell, JSON lub kod JavaScript (od razu możemy przejść przez link do edytora online CodePen).
































Ostatni cmdlet w skrypcie definiuje nam nowy temat kolorystyczny na poziomie tenanta Office 365.
Warto przy okazji zauważyć, że oba cmdlety użyte w skrypcie znajdują się nie w domyślnym module administracyjnym Sharepoint Online ale w module SharePointPnPPowerShellOnline, czyli module Powershell udostępnionym w ramach Sharepoint Patterns and Practices (PnP). Moduł możemy sobie zainstalować ze standardowego repozytorium PSGallery (o konfiguracji komputera do administrowania Office 365 pisałem kilka miesięcy temu), uzyskując w ten sposób wiele dodatkowych możliwości zarządzania SPO.
Mając dodany na poziomie tenanta temat kolorystyczny, możemy go ręcznie przypisać do site'u (rysunek poniżej), albo użyć w konfiguracji domyślnego szablonu dla kolejnych witryn.
W tym celu musimy utworzyć plik JSON z definicją sitescriptu (poniżej), a następnie po połączeniu się do serwisu SPO, wykonać następujące polecenia:

$siteScript = (Get-Content 'c:\Scripts\TeamSite\spsitescript.json' -Raw | Add-SPOSiteScript -Title "ThemeDemo" -Description "Applies theme and nav link")  | Select -First 1 Id
Add-SPOSiteDesign -Title "Theme" -WebTemplate "64" -SiteScripts $siteScript.Id -Description "Applies standard company theme to site" -IsDefault


Pierwsza sekwencja tworzy site script na podstawie zawartości pliku JSON i zwraca identyfikator skryptu, a druga komenda tworzy zmodyfikowany szablon TeamSite (szablonu WebTemplate o numerze 64) i ustawia go jako domyślny dla naszego tenanta ($siteScript.Id to właśnie identyfikator naszego skryptu).
Jeżeli chcielibyśmy dostosować Site typu Communication, powinniśmy użyć WebTemplate o wartości 68. Jeżeli zostało wprowadzone ograniczenie na tworzenie zespołów Office 365, to żeby stworzyć Site typu zespołowego ale bez grupy Office 365, to WebTemplate powinien mieć wartość 1.
Zawartość JSON spssitescript.json wygląda następująco:
{
    "$schema": "schema.json",
        "actions": [
            {
                "verb": "addNavLink",
                "url": "https://techcommunity.microsoft.com",
                "displayName": "Aswers from Community",
                "isWebRelative": false
            },
            {
                "verb": "applyTheme",
                "themeName": "yellowTheme"
            }
        ],
        "binddata": {},
        "version": 1
}
Jak można się domyślić, patrząc na składnię pliku, definiowane są dwie akcje, które będą dodatkowo wykonywane podczas tworzenia nowej witryny typu TeamSite - dodawana jest pozycja do menu nawigacyjnego (link do portalu Techcommunity) oraz ustawiany jest temat kolorystyczny (zdefiniowany wcześniej na poziomie tenanta) widać to wyraźnie, gdy uruchomimy kreator tworzenia nowej witryny zespołu z poziomu portalu Sharepoint Online (rysunek poniżej).



















Więcej informacji na temat możliwych akcji przekazywanych przez JSON i poprawnej składni można znaleźć w dokumentacji Sharepoint. Inne przykłady zastosowania sitescriptów i dostosowywania wyglądu site'ów sharepoint Online można znaleźć na blogu Laury Kokkarinen. Jeżeli ktoś woli prezentację wideo, to warto obejrzeć również ten filmik.

04 czerwca 2016

Office Servers Summit 2016


Już 21 czerwca w siedzibie Microsoft odbędzie się konferencja Office Servers Summit 2016, na której wszyscy polscy MVP w kategorii Office Servers & Services powiedzą, co ciekawego i nowego można zobaczyć w technologiach serwerowych rodziny Office 2016. Chociaż Skype dla firm pojawił się ponad rok temu, a Exchange 2016 przeszło pół roku temu, to premiera Sharepointa 2016 i Office Online Servera 2016 odbyła się zaledwie kilka tygodni temu. Co więcej, Sharepoint 2016 w połączeniu z SQL 2016, którego premiera miała miejsce zaledwie trzy dni temu zyskuje dodatkowe możliwości (np. w zakresie BI). Pozostałe produkty również się zmieniają (np. w Office 365 co miesiąc pojawiają się nowe funkcjonalności). Dodatkowo Jakub Galus z Audiocodes opowie o narzędziach do integracji Skype for Business Online z telefonią stacjonarną. Warto więc przyjść i sprawdzić. Zapraszam do rejestracji na konferencję - http://officeserverssummit2016.evenea.pl/

16 marca 2016

3.2.1.Wydano!

W zeszłym roku Microsoft wydał Skype for Business 2015 i Exchange 2016 ale nadal rodzina Office Servers 2016 nie była gotowa - brakowało Sharepointa. W poniedziałek 14 marca Sharepoint Server 2016 uzyskał status RTM i w końcu można powiedzieć o pełnej rodzinie produktów. Co prawda będzie dostępny do pobrania dla klientów wolumenowych dopiero na początku maja, ale wersję ewaluacyjną można pobrać już dziś. Razem z Sharepointem pojawił się również Project Server 2016 - produkt mocno powiązany. 4 maja ma odbyć się wirtualna premiera produktu, a chętni mogą przeczytać o nowych funkcjonalnościach w dokumencie Sharepoint Server 2016 Overview Guide.
Mam nadzieję, że niebawem będę mógł również zaprosić na Office 2016 Community Launch, ale to na razie jeszcze tajemnica ;)

05 lipca 2014

Publikacja Sharepoint 2013 na Kempie i SSO

Konfigurując usługi Exchange i Lync czasem również mam okazję wykonać pewne akcje integracyjne dla Sharepointa. Publikacja Exchange i Lynca z wykorzystaniem zewnętrznych Load Balancerów jest dobrze opisana, zarówno przez producentów tych urządzeń jak i przez Microsoft, jednak w zakresie publikacji usług Sharepoint trudno znaleźć w internecie procedurę w tym zakresie. Zwłaszcza, że ze względu na kończące się wsparcie dla TMG, jeżeli firma chce opublikować swoją witrynę z dodatkowym zabezpieczeniem problem ten nabiera dodatkowego wymiaru. Niedługo Kemp udostępni niebawem dokumentację opisującą publikację usług Sharepointowych, jednak jak na razie tylko w zakresie pojedynczej witryny portalu firmowego.

Wielu administratorów wykorzystuje konfigurację Sharepointa, gdzie portal firmowy wykorzystuje krótką nazwę, np. http://intranet lub http://portal, a witryny użytkowników wykorzystują witrynę http://mysite. Jak w takim wypadku poprawnie opublikować Sharepointa dla naszych pracowników/współpracowników w internecie, tak żeby nie musieli przechodząc między tymi witrynami ponownie się uwierzytelniać?

Pierwszą kwestią jest oczywiście AAM (alternative access mapping). Chociaż można i bez tego skonfigurować publikację na Kempie, jednak dla porządku i spójności architektury dobrze jest zdefiniować publikację po https, z wykorzystaniem dostępnej z internetu nazwy hosta – np. https://intranet.pepug.org i https://mysite.pepug.org. Niestety Sharepoint zmusza nas do dodania certyfikatów dla tych witryn po stronie serwera IIS z poziomu konsoli IIS Managera oddzielnie, ale jak się o tym pamięta, to nie powinno być problemów.

Kolejnym krokiem jest dodanie na witrynie Sharepointowej możliwości uwierzytelnienia typu Basic.Zarówno dla witryny intranet jak i mysite. Jest ot bardzo proste, ale miejsce, gdzie to należy ustawić nie jest już takie oczywiste (przynajmniej dla mniej zaawansowanych). Należy zatem w centralnej konsoli administracyjnej Sharepointa wejść w zarządzanie aplikacjami (Central Administration-Application Management-Manage Web Application). Wybrać daną witrynę (na rysunku wybrana witryna intranet), a następnie kliknąć w przycisk Authentication Providers. Wybieramy z listy dostępnego providera (jeżeli nie konfigurowaliśmy Sharepointa w specyficzny sposób, powinien być tylko jeden – domyślny) – rysunek 2, a następnie zaznaczamy checkbox przy uwierzytelnieniu Basic (rysunek 3).

Wybór Authentication providerów dla aplikacji

Rysunek 1. Konfiguracja opcji uwierzytelniania dla aplikacji

Wybór providera

Rysunek 2. Wybór providera

Dodanie uwierzytelnienia typu basic do sposobów uwierzytelnienia

Rysunek 3. Włączenie uwierzytelniania typu Basic

Oczywiście po tym niezbędny będzie restart IIS-a, ale nie musimy za to ręcznie zmieniać ustawień w IIS Managerze.

Przejdźmy teraz do publikacji witryny (lub całej farmy, jeżeli mamy kilka FrontEndów Sharepointa).

Na Kempie tworzymy nową wirtualną usługę, do której dodajemy dwa subinterface’y powiązane z każdą z naszych witryn:

Standardowe opcje publikacji, zalecane dla Sharepointa przez Kempa

Rysunek 4. Standardowe opcje publikacji, zalecane dla Sharepointa przez Kempa

Na poziomie głównym serwisu dodajemy również certyfikat – bądź to zawierający obie nazwy publiczne, bądź to wildcardowy dla naszej domeny.

Subinterface’y dodane dla naszych witryn

Rysunek 5. Subinterface’y dodane dla naszych witryn

Teraz musimy utworzyć reguły,  które pozwolą wybrać z tej listy odpowiednią witrynę na podstawie nagłówka zapytania https, przekazanego przez klienta – jedną dla witryny intranet, jedną dla mysite:

Tworzenie reguły na podstawie nazwy witryny

Rysunek 6. Tworzenie reguły na podstawie nazwy witryny

Następnie we właściwościach zaawansowanych witryny włączamy content switching:

Włączenie content switchingu dla wirtualnej usługi

Rysunek 7. Włączenie content switchingu dla wirtualnej usługi

Teraz trzeba tylko przypisać odpowiednią regułę do obu witryn:

Dodanie reguły przełączania dla subinterface’u

Rysunek 8. Dodanie reguły przełączania dla subinterface’u

Dodanie reguły – wybór z listy reguł

Rysunek 9. Dodanie reguły – wybór z listy reguł

Po dodaniu reguł będzie o tym informacja pokazana we właściwościach subinterface’ów.

Lista subinterface’ów z informacją o przypisanych regułach wyboru treści

Rysunek 10. Lista subinterface’ów z informacją o przypisanych regułach wyboru treści

Ostatni punkt programu to skonfigurowanie ESP (Edge Security Pack) dla każdej z naszych witryn. W ramach konfiguracji ESP należy skonfigurować SSO, czyli w tym wypadku komunikację z kontrolerem/kontrolerami naszej domeny Active Directory.

Konfiguracja domeny dla SSO

Rysunek 11. Konfiguracja domeny dla SSO

Jeżeli na Kempie wcześniej było konfigurowane SSO dla Exchange, to nie musimy tego robić, wystarczy wybrać z listy już dostępnych domen.

Konfiguracja ESP dla subinterface’u

Rysunek 12. Konfiguracja ESP dla subinterface’u

W ten sposób publikujemy obie witryny. Wpisując w przeglądarce adres https://intranet.pepug.org pojawi nam się formularz logowania, po wpisaniu nazwy użytkownika domenowego i hasła zalogujemy się do portalu, po kliknięciu na odnośnik “O mnie” zostaniemy przekierowani do drugiej publikowanej witryny http://mysite.pepug.org, bez konieczności dodatkowego uwierzytelnienia. Jeżeli wpiszemy url naszej witryny OWA np. https://owa.pepug.org/owa, to również korzystając z SSO zostaniemy zalogowani do strony OWA naszego Exchange.

21 sierpnia 2013

Problemy z poprawkami Microsoft - WAS

Ostatnio Microsoft nieźle namieszał w kwestii poprawek. Ku pamięci i przestrodze dla innych zapiszę kilka uwag w tym temacie.

Jednym z niemiłych faktów, jaki mnie ostatnio zaskoczył był problem z Office Web Apps Serverem 2013 (WAS). Skonfigurowaliśmy serwer, po jakimś czasie zostały zainstalowane poprawki z Windows Update, między innymi do WAS-a, no i zaczęło sypać błędami (przeważnie 1000 i 1026 – obrazki poniżej).

image

image

Utylizacja procesorów serwera WAS skoczyła na 100%, z czego większość zasobożernych procesów była związana z obsługą błędów.

Okazało się, że automatyczna instalacja poprawek skutecznie rozwaliła konfigurację Office Web Apps Servera 2013. Na szczęście jest ona stosunkowo prosta. Niestety, poprawka KB2760445 nie ma opcji odinstalowania, co powoduje konieczność odinstalowania WAS, zainstalowania go ponownie, wgrania poprawek i dopiero w tym momencie ponownego skonfigurowania farmy WAS (lub dodania danego serwera do farmy składającej się z kilku serwerów (Remove-OfficeWebAppsMachine). Procedura instalacji poprawek do WAS opisana jest na stronach dokumentacji produktu.

Tylko dlaczego te poprawki są dostępne przez Windows Update?

24 października 2010

SBS 2008 - Step-by-Step Guide migracji z Windows SharePoint Services 3.0 do Microsoft SharePoint Foundation 2010

Jakiś czas temu pisałem o problemach związanych z migracją WSS 3.0 do Sharepoint Foudation 2010. Korzytałem przy tym z dokumentu Step-by-Step, który jak widzę jest już udostępniony na stronach Technet. Co prawda nie wspomina polskiej wersji systemu, ale procedura jest analogiczna, niezależnie od wersji językowej systemu.

19 października 2010

Publiczna beta Office 365

Dzisiaj została udostępniona publiczna beta nowej wersji BPOS, opartej na Exchange 2010 SP1, Sharepoint 2010 i Lync 2010. Nowa wersja, na początku określana jako BPOS vNext, została publicznie udostępniona jako Office365.

imageKolejka do testów długa i póki co niedostępna dla Polski, ale już niedługo powinna zawitać i pod nasze strzechy.

22 lipca 2010

Migracja Windows Sharepoint Services 3.0 do Sharepoint Foundation 2010

Ostatnio trochę walczyłem z migracją Sharepoint Services 3.0 do wersji Sharepoint Foundation 2010 w środowisku SBS. Chociaż taki scenariusz jeszcze nie jest oficjalnie wspierany przez Microsoft, jednak jest możliwy do realizacji. Ponieważ instalacje SBS 2008, z którymi mam doczynienia pracują w polskiej wersji językowej, więc migrację również przeprowadzałem z polską wersją Sharepoint Foundation 2010. Co ciekawe okazało się, że niektóre elementy (listy), mają angielskie nazwy (np. categories), a SF2010 koniecznie chce się odwoływać poprzez polskie nazwy. Problemy z tym związane dyskutowałem na forum WSS. Ostatecznym rozwiązaniem było uruchomienie Sharepoint Designera 2010 i ręczna zmiana nazw list.

Przy okazji migracji znalazłem bezpłatne, ciekawe narzędzie - SharePoint Content Deployment Wizard, służące do backupowania/migrowania Sharepointa. Narzędzie jest dobrze opisane na blogu Chrisa O’Brien’a. Narządko niewielkie, a działa bardzo fajnie.