Kwestia niby banalna – czasami przesyłamy sobie pliki typu .xml, .lnk czy inne, które domyślnie są w zabezpieczeniach Outlook Web Apps serwerów Exchange blokowane. W poprzednich wersjach Exchange można było sobie to w wygodny sposób sprawdzić i wyedytować w konsoli graficznej, jak widać na rysunku 1, ale w Exchange Admin Center (Exchange 2013) niestety opcja ta jest niedostępna, co pokazuje rysunek 2.

Image may be NSFW.
Clik here to view.

Rysunek 1. Lista  blokowanych typów plików w EMC w Exchange 2010

Image may be NSFW.
Clik here to view.

Rysunek 2. Dostęp do plików w EAC w Exchange 2013

Oczywiście atrybut BlockedFileTypes i AllowedFileTypes można sprawdzić w Management Shellu, ale są to atrybuty tablicowe, wartości jest dużo i nie jest to zbyt wygodne. Niemniej jednak nie jest to takie trudne. Dla osób, które nie chcą samemu wymyślać koła, poniżej krótka procedura:

Get-OwaVirtualDirectory | fl *blocked*

$owa = get-OwaVirtualDirectory

$blockedtypes = $owa.blockedfiletypes

$blockedtypes -= ".xml"

Get-OwaVirtualDirectory | Set-OwaVirtualDirectory -BlockedFileTypes $blockedtypes

Get-OwaVirtualDirectory | fl *allowedfile*

$owa = get-OwaVirtualDirectory

$allowedtypes = $owa.allowedfiletypes

$allowedtypes += ".xml"

Get-OwaVirtualDirectory | Set-OwaVirtualDirectory -AllowedFileTypes $types

Po restarcie usługi IIS załączniki powinny wyświetlać się poprawnie. W zasadzie moglibyśmy próbować tylko połowy procedury – usunięcie typu pliku z listy blokowanych powinno nam rozwiązać problem, ale lepiej dodać jawnie do listy dozwolonych. Co ciekawe, jeżeli dane rozszerzenie jest na liście zablokowanych typów, to pozwoli się dodać do listy dozwolonych, ale nie będzie się pokazywać.

Kilka tygodni temu sprawdzałem możliwości współpracy modelu hybrydowego dla organizacji korzystającej z Offce365 i zauważyłem, że większość dokumentacji mówi wyłącznie o DirSync-u na systemie nie nowszym niż Windows 2008R2 i ADFS 2.0 RTW (który nie jest wspierany na platformie Windows 2012) do obsługi Single SignOn. Jednak dzisiaj znalazłem informacje, wskazujące na możliwość wykorzystania Windows 2012 Standard lub Datacenter zarówno jako serwer DirSynca, jak i dla Single SignOn. W tym drugim przypadku należy pamiętać o zainstalowaniu w Windows 2012 systemowej roli ADFS (ADFS 2.1) oraz pobraniu Windows Azure AD Module for Windows PowerShell. Mam nadzieję, że w najbliższych dniach zweryfikuję to własnoręcznie.Niestety realizawana od kilku miesięcy przebudowa portalu Microsoft Technet, zwłaszcza działu Downloads, nie ułątwia znalezieniu odpowiednich informacji. Warto jednak zajrzeć na stronę Wiki technologii Azure, gdzie jest podlinkowanych dużo informacji na temat zarówno synchronizacji jak i SSO.

Niedawno pisałem na tym blogu o sprawdzaniu komponentów serwera Exchange. Ponieważ standardowe cmdlety niezbyt wygodnie prezentują stan komponentów, zacząłem używać skryptu, który opublikował na swoim blogu Michael Van Horenbeeck. Jednak oryginalny skrypt tylko sprawdzał stan komponentów, więc postarałem się go trochę rozbudować. Wykorzystałem do tego funkcję get-choice, opracowaną dwa lata wcześniej przez Andy Schneidera. Oczywiście można to zrobić na wiele sposobów, ale uznałem, że wygodnie będzie dać możliwość wyboru, czy na pewno chcemy dany komponent ponownie aktywować. Jeżeli znajdę czas ja albo Michael to skrypt będzie rozbudowany.

Poniżej skrypt:

<!--

Code highlighting produced by Actipro CodeHighlighter (freeware)
http://www.CodeHighlighter.com/

--><#
.SYNOPSIS
       Checks component state of local Exchange 2013 server and give choice to activate any inactive component
.DESCRIPTION
       Checks component state of local Exchange 2013 server. You have choice to activate any inactive component
.NOTES
    Prepared by Konrad Sagala
    Sched Task Required    : No
    Exchange Version    : 2013
    Disclaimer           : You running this script means you won't blame me if this breaks your stuff.
    Code used in script    : First version of this script prepared by Michael Van Horenbeeck, function new-choice by Andy Schneider
.LINK
    http://michaelvh.wordpress.com/tag/compontent-state/
.LINK
    http://poshcode.org/2660
.EXAMPLE
        .\Query-componentstates.ps1
.INPUTS
        None. You cannot pipe objects to this script. But you can add server name.
#>

function New-Choice {
<#
    .SYNOPSIS
        The New-Choice function is used to provide extended control to a script author who writing code 
        that will prompt a user for information.

    .PARAMETER  Choices
        An Array of Choices, ie Yes, No and Maybe

    .PARAMETER  Caption
        Caption to present to end user

    .EXAMPLE
        PS C:\> New-Choice -Choices 'Yes','No' -Caption "PowerShell makes choices easy"

    .NOTES
        Author: Andy Schneider
        Date: 5/6/2011
#>

[CmdletBinding()]
param(

    [Parameter(Position=0, Mandatory=$True, ValueFromPipeline=$True)]
$Choices,

    [Parameter(Position=1)]
$Caption,

    [Parameter(Position=2)]
$Message    

)

process {

$resulthash += @{}
for ($i = 0; $i -lt $choices.count; $i++) 
            {

$ChoiceDescriptions += @(New-Object System.Management.Automation.Host.ChoiceDescription ("&" + $choices[$i]))
$resulthash.$i = $choices[$i]
            }
$AllChoices = [System.Management.Automation.Host.ChoiceDescription[]]($ChoiceDescriptions)
$result = $Host.UI.PromptForChoice($Caption,$Message, $AllChoices, 1)
$resulthash.$result -replace "&", ""
        }         
}

#
# main part of the script
#
$localserver = $env:computerName
$components = Get-ChildItem HKLM:\SOFTWARE\Microsoft\ExchangeServer\v15\ServerComponentStates\ -Recurse | select PSPath

foreach($component in $components){

$componentstates = (Get-ItemProperty $component.PSPath | Select * -ExcludeProperty PS* ) | Get-Member -MemberType NoteProperty

$i=0

do {

$componentstate = ($componentstates[$i].Definition).split("=")
$statebreakdown = $componentstate[1].Split(":")

#$componentActualState = $statebreakdown[1]
        
switch($statebreakdown[1]){
1 {$componentActualState = "Active"}
0 {$componentActualState = "Inactive"}
        }
$componentActualTime = [timezone]::CurrentTimeZone.ToLocalTime([datetime]::FromBinary($statebreakdown[2]))

$obj = New-Object PSObject
$obj | Add-Member -MemberType NoteProperty -Name Component -Value $($component.PSPath.Split("\"))[7]
$obj | Add-Member -MemberType NoteProperty -Name Requester -Value $componentstates[$i].Name
$obj | Add-Member -MemberType NoteProperty -Name State -Value $componentActualState
$obj | Add-Member -MemberType NoteProperty -Name TimeStamp -Value $componentActualTime
$obj

$i++
if ($componentActualState -eq 'Inactive')
            {
$answer = New-Choice -Choices 'Yes','No' -Message "Do you want to activate component?"
if ($answer -eq 'Yes')
                {
                    Set-ServerComponentState -Identity $localserver -Component $obj.Component -Requester $obj.Requester -State Active
                }
            }
    }
while ($i -lt $componentstates.count)
}

Konfigurując dzisiaj zdalny dostęp do pewnego środowiska przy pomocy klienta Checkpoint VPN zainstalowałem kilka wersji, ale połączenie nie chciało działać poprawnie. Wtedy zgodnie ze starą zasadą RTFM sięgnąłem do informacji na stronie pomocy technicznej Checkpointa. Okazało się, że w celu skonfigurowania połączenia VPN do organizacji zabezpieczonej przez urządzenia Checkpointa nie trzeba instalować dodatkowych klientów – Windows 8.1 ma wbudowany plug-in klienta VPN Checkpointa. Jednak, powinno się go skonfigurować z powershella. Odpowiedni skrypt i krótką instrukcję użycia można znaleźć na stronie pomocy technicznej Checkpointa. Po pobraniu skryptu uruchamiamy go, podając nazwę gatewaya i alias, pod którym ma być widoczny na liście połączeń VPN:

config.ps1 -gateway GATEWAY [-name NICKNAME]

W podobny sposób możemy usunąć informacje o połączeniu VPN:

config.ps1 -name NICKNAME –remove

Można podać również dodatkowe parametry, ale nie jest to niezbędne – zestawiając połączenie możemy podać dodatkowe informacje, takie jak sposób uwierzytelnienia.

Co ciekawe, tak skonfigurowane połączenie wygląda identycznie jak inne połączenia VPN, skonfigurowane z użyciem standardowego klienta Microsoft VPN.

Zmiana nazw wirtualnych katalogów (a w zasadzie nazwy hosta, przez którą dostają się do Exchange klienci) wymaga wykonania wielu cmdletów (nie wszystkie nazwy można zmienić z poziomu narzędzi webowych). Łatwo przy tym coś przeoczyć lub po prostu zrobić literówkę. Jakiś czas temu opublikowałem w galerii skryptów na Technecie skrypt do listowania wszystkich tych nazw i spotkał się z ciepłym przyjęciem (ponad 500 pobrań). Teraz przygotowałem, na podstawie skryptu dla starszej wersji Exchange taki skrypcik dla Exchange 2013 i również opublikowałem na Technecie.

https://gallery.technet.microsoft.com/Set-all-virtual-directories-f4ec71d3 

Wydaje mi się, że jest dosyć przejrzysty, jak widać na poniższym rysunku:

Image may be NSFW.
Clik here to view.

Oczywiście, po wykonaniu skryptu należy wykonać restart IIS (najlepiej komendą iisreset /noforce /timeout:5000) na każdym modyfikowanym serwerze.

Jedną z ciekawych i ciągle mało znanych funkcjonalności w Exchange 2013 (chociaż pojawiła się już w Exchange 2010) jest możliwość wykorzystania agenta skryptowego do realizowania dodatkowych akcji po wykonaniu standardowego cmdleta Exchange. Przykładem może być operacja tworzenia skrzynki Exchange – enable-mailbox lub new-mailbox nie posiadają opcji pozwalających np. na ustawienie domyślnego języka i strefy czasowej. Przypomniał o tym ostatnio Tony Redmond na swoim blogu. Podobnie w przypadku włączenia funkcjonalności SingleItemRecovery lub audytowania musimy wykonać dodatkowe operacje. Automatyzację konfiguracji tych parametrów umożliwia nam dodatek Cmdlet Extension Agents, a tak naprawdę to jeden z 8 agentów – Scripting Agent:

Image may be NSFW.
Clik here to view.

Jak możemy go użyć?

W katalogu instalacyjnym Exchange, w podkatalogu BinCmdletExtensionAgent znajdują się niezbędne rozszerzenia oraz przykład pliku konfiguracyjnego jak widać na poniższym rysunku:

Image may be NSFW.
Clik here to view.

Tworząc plik konfiguracyjny (obowiązkowa nazwa ScriptingAgentConfig.xml)definiujemy w nim, dla jakich komend wykonywane są dodatkowe operacje i jakie są warunki początkowe. W przypadku uzupełnienia operacji tworzenia skrzynki w pliku xml dodajemy sekcję dla odpowiednich komend i uzależniamy wykonanie sekwencji dodatkowych czynności od poprawności wykonania komendy podstawowej (weryfikując rezultat zwrócony przez metodę “OnComplete”). Oczywiście możemy dodać więcej operacji. Poniższy plik opisuje operację ustawienia polskiej wersji językowej, godziny rozpoczęcia pracy w firmie, polskiej strefy czasowej. Włączone zostaje również SingleItemRecovery oraz audytowanie operacji na skrzynce (tylko administrator i delegaci, żeby włączyć audytowanie dla właściciela należy dodatkowo zdefiniować, jakie operacje są rejestrowane).

<?xml version="1.0" encoding="utf-8" ?>
<Configuration version="1.0">
    <Feature Name="Mailboxes" Cmdlets="New-Mailbox, Enable-Mailbox">
        <ApiCall Name="OnComplete">
        if($succeeded) {
            $Name= $ProvisioningHandler.UserSpecifiedParameters["Name"]
            Set-Mailbox $Name -Languages "pl-PL"
            Set-MailboxRegionalConfiguration $Name -DateFormat "yyyy-MM-dd" -TimeZone "Central European Standard Time"
            Set-MailboxCalendarConfiguration $Name -WorkingHoursStartTime "09:00:00"
            Set-Mailbox $Name -SingleItemRecoveryEnabled $true
            Set-Mailbox $Name -AuditEnabled $true
        }
        </ApiCall>
    </Feature>
</Configuration>

Plik musi znajdować się na wszystkich serwerach z rolą Mailbox. W ten sposób, jeżeli nie popełniliśmy błędu dla każdej nowo tworzonej skrzynki, zostaną ustawione parametry pokazane powyżej, niezależnie czy będzie ona tworzona z poziomu Exchange Management Shella czy konsoli webowej.

Oczywiście musimy najpierw włączyć agenta komendą:

Enable-CmdletExtensionAgent “Scripting Agent”

Niedawno pisałem o wykorzystaniu extension agenta w Exchange 2013. Kolejny ciekawy przykład wykorzystania rozszerzenia scripting agenta można znaleźć na blogu PFE. Jeżeli chcemy monitorować zmiany uprawnień na skrzynkach bardzo ważnych osób w naszej firmie, wystarczy do pliku ScriptingAgentConfig.xml (tworzenie pliku opisałem we wspomnianym wcześniej poście) dodać sekcję, dodającą akcję dla cmdleta Add-MailboxPermission:

<Feature Name="EventWrite" Cmdlets="Add-MailboxPermission">

<ApiCall Name="OnComplete">

$GrantedPermissionUser = $provisioningHandler.UserSpecifiedParameters["User"]

$identity = Get-Mailbox $provisioningHandler.UserSpecifiedParameters["Identity"]

$Alias = (Get-Mailbox "$identity").alias

$AccessRights = $provisioningHandler.UserSpecifiedParameters["AccessRights"]

if ($AccessRights -eq "FullAccess")

{

if ( @("CEO_Alias","CFO_Alias","COO_Alias") -like $alias)

{

write-eventlog -logname Application -source MailboxAudit -eventID 100 -entrytype Error -message "$GrantedPermissionUser was given Full Mailbox Access to $identity's Mailbox."

}

}

</ApiCall>

</Feature>

W ten sposób dla aliasów zdefiniowanych w tablicy @("CEO_Alias","CFO_Alias","COO_Alias"), akcja poprawnie zakończonego dodania uprawnień zostanie zakończona wygenerowaniem zdarzenia w application logu o wskazanym przez nas eventId i komunikacie. Oczywiście możemy dodać inną akcję – np. wysłanie maila do oficera bezpieczeństwa.

Dawno nie pisałem, ale nadmiar pracy i testy nowych technologii, które miały status NDA trochę mi to utrudniały. Ale żeby nie zapomnieć chciałem dodać jedną informację o używaniu Direct Access. Jest to świetna technologia, człowiek cały czas podłączony jest do lokalnych zasobów firmowych, może używać krótkich nazw serwisów intranetowych niezależnie od tego, gdzie jest podpięty. Jednak czasem bywa to uciążliwe, zwłaszcza gdy chcemy sprawdzić poprawność publikowanych usług od strony Internetu. Do wyłączenia Direct Accessa niezbędne jest zatrzymanie dwóch usług systemowych – asystenta usług sieciowych i IP Helpera, co w normalnych warunkach wymaga odpalenia konsoli services.msc, znalezienia odpowiednich usług i ich zatrzymanie. Oczywiście odwrócenie konfiguracji wymaga włączenia tych usług lub restart komputera. Dużo szybciej jest przygotować sobie skrypt powershell, który możemy “prawokliknąć” i wybrać opcję “Run with powershell”. Cały problem polega na tym, że zatrzymanie usług wymaga odpalenia skryptu z wyższymi uprawnieniami (nieszczęsny UAC). Pomyślałem sobie, że najprościej włączyć eskalację uprawnień wewnątrz skryptu, co też uczyniłem, wykorzystując konstrukcję opisaną na blogu Bila Armstronga - http://blogs.msdn.com/b/virtual_pc_guy/archive/2010/09/23/a-self-elevating-powershell-script.aspx:

#
# script to stop Direct Access on user computer
# if user has local administrator permission
#

# Get the ID and security principal of the current user account
$myWindowsID=[System.Security.Principal.WindowsIdentity]::GetCurrent()
$myWindowsPrincipal=new-object System.Security.Principal.WindowsPrincipal($myWindowsID)
 
# Get the security principal for the Administrator role
$adminRole=[System.Security.Principal.WindowsBuiltInRole]::Administrator
 
# Check to see if we are currently running "as Administrator"
if ($myWindowsPrincipal.IsInRole($adminRole))
    {
    # We are running "as Administrator" - so change the title and background color to indicate this
    $Host.UI.RawUI.WindowTitle = $myInvocation.MyCommand.Definition + "(Elevated)"
    $Host.UI.RawUI.BackgroundColor = "DarkBlue"
    clear-host
    }
else
    {
    # We are not running "as Administrator" - so relaunch as administrator
   
    # Create a new process object that starts PowerShell
    $newProcess = new-object System.Diagnostics.ProcessStartInfo "PowerShell";
   
    # Specify the current script path and name as a parameter
    $newProcess.Arguments = $myInvocation.MyCommand.Definition;
   
    # Indicate that the process should be elevated
    $newProcess.Verb = "runas";
   
    # Start the new process
    [System.Diagnostics.Process]::Start($newProcess);
   
    # Exit from the current, unelevated, process
    exit
    }
 
 
stop-service NCASvc
stop-service iphlpsvc

Na podobnej zasadzie można oczywiście realizować inne operacje cykliczne operacje, np. zmiany adresu IP.

Zaczął się sezon na migracje, także do Exchange 2016. Jednym z elementów konfiguracji jest odpowiednie przygotowanie wirtualnych katalogów dla roli CAS. Exchange od dawien dawna dla  każdej z usług webowych udostępnia nazwę zewnętrzną (exernal URL) i wewnętrzną (internal URL). Od Exchange 2013 ten dualizm dotyczy również usługi Outlook Anywhere – wcześniej można było zdefiniować tylko publiczną nazwę hosta dla tej usługi. Żeby było ciekawiej, nie wszystkie nazwy można skonfigurować przez Exchange Admin Center, co utrudnia proces. Dla jednego serwera musimy zdefiniować więc następujące URL-e:

• dwa dla usługi ActiveSync,
• dwa dla OWA,
• dwa dla ECP,
• dwa dla OAB,
• dwa dla EWS,
• dwa dla Outlook Anywhere,
• dwa dla Poweshell,
• dwa dla MAPI (jeżeli włączamy ten typ dostępu),
• jeden dla Autodiscover (jako atrybut serwera CAS)

Daje nam to 17 URL-i na jeden serwer (!), czyli całkiem sporo. A jeżeli w organizacji mamy kilka takich serwerów do skonfigurowania daje nam to odpowiednio więcej wpisów. Jakiś rok temu, żeby zaoszczędzić sobie pracy przygotowałem (a w zasadzie uaktualniłem) skrypt, który automatyzuje ten proces, jak widać na poniższym rysunku. W ostatni weekend znalazłem chwilę, żeby to trochę poprawić i dopasować do Exchange 2016. Zapraszam do korzystania i przekazywania sugestii na temat możliwych ulepszeń.

Image may be NSFW.
Clik here to view.