からめもぶろぐ。

俺たちは雰囲気で OAuth をやっている

削除できなくなった SharePoint 2013 ワークフローを強制的に削除する

SharePoint Designer で SharePoint 2013 ワークフローを開発しているとまれに作成したワークフローを削除できなくなることがあります。具体的には、再利用可能なワークフローを作成し、テンプレートとして保存し、保存したテンプレートから展開した場合に、ワークフローが削除できなくなることが確認できています。この場合、SharePoint Designer で削除できないだけでなく、CSOM から WorkflowDeploymentService.DeleteDefinition メソッドを呼び出しても削除できません。
削除できないと最悪サイトの作り直しになってしまいますので、頑張って無理やり削除してみたいと思います。

まず、SharePoint 2013 ワークフローの情報はどこに格納されているかというと「wfsvc」という隠しドキュメントライブラリにあります。「wfsvc」は GUI からも SharePoint Designer からも見えませんが、CSOM からであれば確認することができます。

試しに SharePoint Designer で SharePoint 2013 ワークフローを作成してみます。

CSOM でワークフローが存在することを確認します。

Add-Type -LiteralPath "$PSScriptRoot\Microsoft.SharePoint.Client.dll"
Add-Type -LiteralPath "$PSScriptRoot\Microsoft.SharePoint.Client.Runtime.dll"

$siteurl = "{{siteurl}}"
$username = "{{username}}"
$password = "{{password}}"

$password = ConvertTo-SecureString $password -AsPlainText -Force
$credentials = New-Object Microsoft.SharePoint.Client.SharePointOnlineCredentials($username, $password)
$context = New-Object Microsoft.SharePoint.Client.ClientContext($siteurl)
$context.Credentials = $credentials

$web = $context.Web
$context.Load($web)
$context.ExecuteQuery()

$list = $web.GetList($web.ServerRelativeUrl.TrimEnd('/') + '/wfsvc')
$query = New-Object Microsoft.SharePoint.Client.CamlQuery
$query.ViewXml = '<View Scope="RecursiveAll"></View>'
$items = $list.GetItems($query)
$context.Load($items)
$context.ExecuteQuery()

foreach ($item in $items) {
    Write-Output ([pscustomobject]@{ Path = $item['FileRef']; Name =  $item['WSDisplayName'] })
}

実行すると以下のような結果が返ってきます。

Path                                                  Name
----                                                  ----
/wfsvc/a1ef7b8ae5554ee18af83707d4bdef88
/wfsvc/a1ef7b8ae5554ee18af83707d4bdef88/workflow.xaml Test Workflow 1

workflow.xaml がワークフローの本体です。よってこれをフォルダーごと削除してしまいます。

$folder = $web.GetFolderByServerRelativeUrl('/wfsvc/a1ef7b8ae5554ee18af83707d4bdef88')
$folder.DeleteObject()
$context.ExecuteQuery()

削除されました!

PowerApps の所有者を PowerShell で変更する

なんか煽られた気がするので書いてみます。

PowerApps で、アプリの作成者が退職したなどの理由でアカウントがなくなってしまった場合、アプリ自体は残り続けます。共有されている場合はまだいいのですが、自分だけで使っていたなどの場合は、誰もアプリを編集できない状態になってしまいます。それを回避するためにアプリの所有者を変更するという手段が提供されています。今回は PowerShell でアプリの所有者を変更してみたいと思います。

まず、組織のアプリの一覧は管理センターから見ることができます。今回は「野良アプリ」の所有者を変更してみます。

PowerApps の管理モジュールは PowerShell Gallery から入手することができます。

www.powershellgallery.com

モジュールをインポートしてログインします。

PS C:\> Import-Module Microsoft.PowerApps.Administration.PowerShell
PS C:\> Add-PowerAppsAccount

アプリの一覧を取得するのは「Get-AdminPowerApp」コマンドを使用します。

PS C:\> Get-AdminPowerApp

AppName                  : 4e3bd861-3ae1-4e15-a5e3-93e8585cbfdd
DisplayName              : パスワード マネージャー
CreatedTime              : 2018-08-24T01:33:36.3124145Z
...

AppName                  : 60ebc075-e5a3-49d3-8163-c216ecc688b0
DisplayName              : 野良アプリ
CreatedTime              : 2019-08-29T06:02:42.8999503Z
...

アプリの所有者を変更するのは「Set-AdminPowerAppOwner」を使用します。パラメーターは (Name とかいう名前になっていますが) すべて GUID で指定します。

PS C:\> Set-AdminPowerAppOwner -AppName 60ebc075-e5a3-49d3-8163-c216ecc688b0 -EnvironmentName Default-92dbed3f-d37a-4f19-a392-f6970505cc6a -AppOwner 4b34f1e2-0c77-4fbd-a8cf-94a4606021ee

Code        :
Description :
Error       :
Errors      :
Internal    : @{name=60ebc075-e5a3-49d3-8163-c216ecc688b0; id=/providers/Microsoft.PowerApps/apps/60ebc075-e5a3-49d3-81
              63-c216ecc688b0; type=Microsoft.PowerApps/apps; tags=; properties=}

変更されました!

SharePoint Online のコミュニケーション サイトではリスト テンプレートやソリューションをアップロードできない

SharePoint Online のコミュニケーション サイトでは、[サイトの設定] - [Web デザイナー ギャラリー] でリスト テンプレートやソリューションのギャラリーへのリンクが表示されず、また直リンクでギャラリーにアクセスしてファイルをアップロードしようとしてもアクセスが拒否されます。この動作は、たとえユーザーがサイト コレクション管理者であっても同様です。

それはそうなのですが、では内部ではどのような仕組みになっているかというと、コミュニケーション サイトのテンプレートでサイト コレクションを作成したときに、SPSite.DenyPermissionsMask プロパティに AddAndCustomizePages が設定されます。この動作は SharePoint 2019 で確認することができます。SharePoint 2019 であれば、SPSite.DenyPermissionsMask プロパティを更新するか、ファーム アカウントでアクセスすると使えるようになるのですが、残念ながら SharePoint Online では、どちらの方法も使えないため、回避策はないようです。

ちなみに、Office 365 グループに接続されたチーム サイトでも同様ですが、Office 365 グループなしのチーム サイトであれば、リスト テンプレートやソリューションは使えるようです。あまり使う機会はないかもしれませんが、覚えておくと何かのときに役に立つかもしれません。

SharePoint 2019 で SharePoint 2013 ワークフローを使用できるようにする

SharePoint Online であれば Flow を使えば問題ないのですが、オンプレミスの SharePoint 2019 の場合は、まだまだ SharePoint ワークフローを利用する機会は多いと思います。そして、標準で使える SharePoint 2010 ワークフローよりも、HTTP Web アクセスでの REST API 呼び出しによる柔軟なワークフロー開発を行うために、SharePoint 2013 ワークフローを使いたいということも多いと思います。SharePoint 2019 でも SharePoint 2013 ワークフローはサポートされていますが、主に Workflow Manager のインストール手順がちょっと変わっていますので、確認してみたいと思います。

構築手順

Web Platform Installer のインストール

まだ生きてたんかい!と思わず突っ込みを入れたくなってしまいますが、Workflow Manager をインストールするためにはまず Web Platform Installer をインストールする必要があります。

www.microsoft.com


Workflow Manager 1.0 のインストール

Web Platform Installer を起動して「Workflow」で検索をかけると Workflow Manager 1.0 が結果に出てきます。まずはこれをインストールします。インストール後、構成を聞かれますが、これはいったんキャンセルしておきます。そして Web Platform Installer も終了させておきます。大変面倒なのですが、Web Platform Installer はインストールの依存関係の情報を起動時にしか読み込んでくれないようなので、この手順は必須になります。


Service Bus 1.0 CU1 のインストール

Workflow Manager 1.0 をインストールすると、同時に Service Bus 1.0 もインストールされますが、こちらの CU が出ているのでインストールします。Web Platform Installer を起動して「Service Bus」で検索をかけると Service Bus 1.0 CU1 が結果に出てきますのでこれをインストールします。インストールが終わったら Web Platform Installer を終了します。


Workflow Manager 1.0 CU5 のインストール

そして今度は Workflow Manager 1.0 CU5 をインストールします。ちゃんと Web Platform Installer を開きなおしていればエラーは出ないはずですが、依存関係でエラーが出る場合は、Web Platform Installer を終了させてから起動しなおしたかどうかを確認してください。


Workflow Manager の構成

ここまでインストールできたらようやく Workflow Manager の構成を行います。なお Workflow Manager の構成でエラーが出る場合、正しく CU が当たっていない可能性があります。
あとは Register-SPWorkflowService コマンドレットを実行して SharePoint Server にワークフローを登録します。ここの手順は SharePoint 2013 と変更ありません。

shanqiai.weblogs.jp

まとめ

CU をインストールする手順が意外に厄介です。インストールの順番と、ちゃんと Web Platform Installer をインストールするごとに終了して起動しなおす、を忘れなければ、トラブルなく構築できるのではないかと思います。

SharePoint Online のモダン UI から「タイトル」列の名前を変えても変わらない現象について

元ネタはこちら。

art-break.net

じゃあなんでこうなるかというと、ざっくり言えば SharePoint には「タイトル」列が 3 つあるからです。[ビューの編集] を見たことがある人ならピンとくるかもしれませんが、以下の 3 つの列が存在します。

ID 表示名 内部名
fa564e0f-0c70-4ab9-b863-0177e6ddd247 タイトル Title
82642ec8-ef9b-478f-acf9-31f7d45fbc31 タイトル (編集メニュー付きのアイテムにリンク) LinkTitle
bc91a437-52e7-49e1-8c4e-4698904b2b6d タイトル (アイテムへのリンク) LinkTitleNoMenu

そしてこれも結局 [ビューの編集] を見ればわかることなのですが、モダン UI から変えたときに名前が変わるのは「タイトル (編集メニュー付きのアイテムにリンク)」列です。[リストの設定] で変更できたり PowerApps から参照されるのは「タイトル」列なので、それはうまくいくはずがありません。

このあたり Schema.xml とかを自分で書いたことがある人でないとなかなか難しいかもしれないですね。