Quantcast
Channel: Japan SharePoint Support Team Blog
Viewing all 182 articles
Browse latest View live

InfoPath 2013 と SharePoint Designer 2013 の Office 2016 や他製品との互換性について

$
0
0

こんにちは SharePoint サポートの森 健吾 (kenmori) です。

導入

InfoPath 2013 や SharePoint Designer 2013 は、Office 2016 に含まれることなく、デスクトップ クライアント アプリケーションとしては最後のバージョンとなりました。サポート ライフサイクルの観点では 2026 年までサポートされます。

また、InfoPath Forms Services SharePoint Server 2016 のサポート ライフサイクルによって 2026 年までサポートされます。SharePoint Online における InfoPath Forms Services も本日 2016 12 16 日のところは削除の予定はなく、告知があるまでは使用できることになっています。

しかし、Office 2016 がリリースされ、InfoPath 2013 SharePoint Designer 2013 とのバージョン不一致からいくつかの問題があることがお問い合わせとして上がっています。

そのうち、よくあるお問い合わせを本ブログでまとめさせていただきます。

 

InfoPath 2013 について

1. データ接続 – メール送信について

InfoPath のデータ接続、データ送信機能には電子メールを送信する機能があります。この際に Outlook がインストールされている環境では、下記のダイアログを表示して Outlook からメールを送信する動作となります。

compat201601

この機能に関する注意点として、InfoPath 2013 が Outlook 2016 に正式に対応したバージョンは InfoPath 2013 の 2014 年 12 月の更新プログラム以降となります。InfoPath 2013 Service Pack 1 (2014 年 2 月時点) では対応していませんので必ずそれ以降のパッチを適用ください。最新版にアップデートすることをお勧めします。

パッチを適用していない状況ですと Outlook の送信ウィンドウが起動したり、エラーになる動作になります。

タイトル : Hotfix KB2883034 for InfoPath 2013 December 9, 2014 (Ipeditor-x-none.msp)
アドレス : https://support.microsoft.com/en-us/kb/2883034
機械翻訳 : https://support.microsoft.com/ja-jp/kb/2883034

Users can submit data to email messages when they install InfoPath 2013 side by side with future versions of Microsoft Office.

なお、上記データ接続の動作は、データ接続および VSTA 経由のいずれで呼び出したとしても同じ動作で、正常動作のためにはパッチ適用が前提です。

 

2. Outlook からのワークフロー タスクを開く動作について

Outlook が InfoPath (IPEDITOR.DLL) をロードして、モーダル ダイアログ上にクライアント フォームをロードし、承認操作を行わせる機能がありました。

compat201602

Outlook 2016 からは、ブラウザー (InfoPath Forms Services) でフォームが開く動作に変わります。

 

3. Visual Studio Tools for Application について

InfoPath 2013 が対応している Visual Studio Tools for Application (VSTA) のバージョンは 2012 のみとなります。

タイトル : Microsoft Visual Studio Tools for Applications 2012
アドレス : https://www.microsoft.com/ja-JP/download/details.aspx?id=38807

VSTA には 2012, 2013, 2015 などと上位のバージョンが存在しますが、InfoPath 2013 が対応しているのは 2012 のみです。

 

SharePoint Designer 2013 について

SharePoint ワークフローのビジュアライゼーションの生成 (*1) と、SharePoint 2013 形式ワークフローのインポート・エクスポート (*.vsdx) (*2) を実施する場合は、現時点 (2016 年 12 月 16 日) のところ Visio 2013 Pro が必要になります。

当初は Visio Pro のバージョンを限定しておりませんでしたが、SharePoint Designer 2013 2015 8 月の修正プログラムから、将来のバージョン (Visio 2016 Pro を含む) に対応しないよう制限が加わっております。

タイトルAugust 11, 2015, update for SharePoint Designer 2013 (KB3039732)
アドレス : https://support.microsoft.com/en-us/kb/3039732
機械翻訳 : https://support.microsoft.com/ja-jp/kb/3039732

SharePoint Designer 2013 still tries to run the Visual Designer function on a computer that does not have Visio 2013 installed.


(*1) ワークフロー ビジュアライゼーションの生成

SharePoint Designer 2013 は Visio Pro 2013 を操作して、ワークフロー発行時にワークフローを可視化するビジュアル デザイナーを生成します。
下記のイメージは、ワークフローの状態画面に表示されます。

compat201606

Visio 2013 Pro がインストールされていない環境では、上記のイメージが生成されません。このことは、SharePoint Designer 2013 のワークフロー発行時に下記のように通知されます。

compat201605

エラー メッセージ

必要な Visio コンポーネントがインストールされていないため、このワークフローには資格エフェクトが作成されません。発行するには、[OK] をクリックしてください。

 

(*2) SharePoint 2013 形式ワークフローのインポート・エクスポート

SharePoint Designer 2013 は、Visio Pro 2013 を操作して、SharePoint 2013 形式ワークフローのインポート・エクスポートを行います。

compat201604

InfoPath 2013 と同様に、SharePoint Designer 2013 Service Pack 1 (2014 年 2 月リリース) だけでは Office 2016 の動作を考慮できておりません。

上記のパッチを当てない状況では一部動作することもありますが、弊社としては最新版にアップデートすることをお勧めします。

以上です。

 

 


Project Online 関連のサブスクリプションについて

$
0
0

こんにちは、SharePoint サポートの森村です。
主に 2016 8 月に公開済みの情報のご案内となりますが、本記事では Project Online に関連する Office 365 サブスクリプションについて関連情報をご案内いたします。

目次
1. 2016 年 8 月の変更について
2. サブスクリプションの移行について

1. 2016 年 8 月の変更について
Project Online 関連のサブスクリプションにつきましては、2016 8 月に、以前の 「Project for Office 365」、「Project Online」、「Project Lite」 という名称から、下記の 3 点のサブスクリプションに内容も含めて変更を行っております。

Project Online Premium」、および 「Project Online Professional」 はブラウザー上で使用する Project Online の機能と、デスクトップ上にインストールする Project Professional 製品のライセンスを含んでいます。また、「Project Online Essentials」 は、従来の 「Project Lite」 と同様に、「Project Online Premium」、および 「Project Online Professional」 と組み合わせて使用するサブスクリプションであり、「Project Online Essentials」 単体では使用できません。
各サブスクリプションの詳細、比較につきましては、上記の各サブスクリプションへのリンク、あるいは以下の関連情報をご確認ください。

タイトル : プランと価格
アドレス : https://products.office.com/ja-jp/project/compare-microsoft-project-management-software

タイトル : Project Online サービスの説明
アドレス : https://technet.microsoft.com/ja-jp/library/project-online-service-description.aspx

2. サブスクリプションの移行について
従来のサブスクリプションをお持ちのお客様には、メッセージセンターにて移行方法をご案内しております。
リンク先の情報は日本語の情報となりますので、併せてご確認ください。

メッセージ センターの情報
タイトル : Project Online and Project for Office 365 subscriptions are changing (MC82292)
アドレス : https://portal.office.com/AdminPortal/home?switchtomodern=true#/MessageCenter?id=MC82292
上記リンクは、管理者権限で Office 365 にサインインした状態で表示可能です。こちらのメッセージは 2016 8 月頃より Project for Office 365 など廃止対象のライセンスをお持ちのお客様の Office 365 管理センターの [メッセージ センター] に案内されております。また、10/21 に発行されております最新のメッセージ “MC82292” につきましては、それ以前のメッセージ “MC75034” の内容を更新したものになります。

上記メッセージのリンク先の情報
タイトル : Project Online をご利用のお客様へプラン変更に関する重要な情報
アドレス : https://support.office.com/ja-jp/article/496aafdd-9f62-4daf-8d2e-0e700925c6b2

今回の投稿は以上です。


本情報の内容(添付文書、リンク先などを含む)は、作成日時点でのものであり、予告なく変更される場合があります。

SharePoint Server におけるホストヘッダーの利用について

$
0
0

こんにちは SharePoint サポートの森 健吾 (kenmori) です。

今回の投稿では、SharePoint Server オンプレミス製品をホストする Web サーバーでホスト ヘッダーを利用する方法や注意点についてご説明します。
新しい情報ではありませんが、代替アクセス マッピングと合わせて質問が多いため、今回情報を公開させていただくに至りました。

なお、ホストヘッダーは、SharePoint Server 2013 から導入されたホスト名付きサイト コレクションには対応していません。本投稿ではホスト名付きサイト コレクションには言及しません。

 

ホストヘッダーの用途

ホストヘッダーを指定すれば、要求アドレスのホスト名をもとに、Web サーバーが到達先の Web サイトを振り分けることができるようになります。そのため、例えば複数の異なる IIS Web サイト (または異なる SharePoint の Web アプリケーション) で同じポート番号 (例. 80, 443) を共有することが可能になります。

ホストヘッダーを指定した場合、HTTP 要求されたアドレスのホスト名とポート番号の両方が合致した Web サイトに要求が振り分けられます。

hostheader1

この機能が利用される背景としては、Web サーバーにおいて、特に 80 番ポート (http://) 443 番ポート (https://) など、URL 表記する際に番号を省略できるポートであるということ。また、ファイアウォール設定などもあるため、あまり多くのポートを開けたくないという要件などもあります。

SharePoint でホストヘッダーを設定できる画面は、新規 Web アプリケーションを作成画面か、Web アプリケーションの拡張画面のみです。

その他の画面で、ホストヘッダーの設定値を変更や参照する画面は用意されていません。(*1)

hostheader3

hostheader4

IIS においてホストヘッダーを設定するのは、下記画面の通り、サイトバインドのホスト名が該当します。

hostheader2

上記の通り、IIS 管理コンソールでサイトのホスト ヘッダーの設定値を参照することは可能ですが、SharePoint は製品として直接 IIS 管理コンソールからサイトのバインドを変更し、ホストヘッダーを指定することを想定しておりません。

もちろん、IIS を基盤にして動作する以上、IIS でサイト バインドを設定するだけで要求の振り分けは可能です。しかし、IIS での設定変更は、構成データベースに格納されませんので、IIS 設定と SharePoint 製品の構成データとの間にかい離が生じます。

このことから、SharePoint 全体管理画面でのオペレーションや PowerShell による管理コマンドの実行時等で、構成データの値に基づき、設定内容が意図せず元に戻ることが想定されます。

また、新しくホストヘッダーを登録する場合や SharePoint ホスト アドインの構築など、製品動作として IIS のバインドを変更する処理はいくつかあります。これらの制御を行うにあたり、構成データベースに設定が格納されていなければ、ホストヘッダーが登録されている前提を考慮した動作ができませんので、様々なシナリオで構成上の不整合を引き起こし、Web サイトにアクセスできなくなる (404 エラー) などの現象発生が想定されます。

 

補足 (*1) ホストヘッダーを確認する方法

SharePoint 全体管理画面でホスト ヘッダーを画面上から確認する方法はありません。IIS 管理コンソールから Web サイトのバインドを確認する方法もありますが、整合性が気になるとお考えの方は、PowerShell を使ってホストヘッダーを照会する方法が有効です。

下記にファーム全体の Web アプリケーション全体における IIS のバインド設定を確認するための PowerShell を用意しましたので、これをお役立ていただけますと幸いです。

 

$global:SPBindings = [System.Collections.ArrayList]@()

function GetBindings($webappurl, $key, $bindings)
{
  foreach ($binding in $bindings)
  {
    $bindtoadd = new-object psobject -property ([ordered]@{WebApplication = $webappurl; Zone = $key; HostHeader = $binding.HostHeader; Port =
$binding.Port})
    [void]$global:SPBindings.add($bindtoadd)
  }
}

foreach ($webApp in (Get-SPWebApplication))
{
  foreach ($key in $webApp.IisSettings.Keys)
  {
    GetBindings -webappurl $webApp.Url -key $key -bindings $webApp.IisSettings[$key].ServerBindings
    GetBindings -webappurl $webApp.Url -key $key -bindings $webApp.IisSettings[$key].SecureBindings
  }
}
$global:SPBindings | select WebApplication, Zone, HostHeader, Port

上記のスクリプトを GetSPBindings.ps1 として保存し、SharePoint 管理シェルで実行します。

PS>.\GetSPBindings.ps1

なお、取得する $SPBindings をグローバル スコープの変数として定義しておりますので、本スクリプト実行後の同じ PowerShell ウインドウで $SPBindings を参照すれば結果が取得できるようにしています。

さらに $SPBindings | fl のようにすることも可能ですし、フィルターやソートなども可能ですので、ご自由に使ってみてください。

タイトル : SPSecureBinding class
アドレス : https://msdn.microsoft.com/en-us/library/microsoft.sharepoint.administration.spsecurebinding(v=office.15).aspx

タイトル : SPServerBinding class
アドレス : https://msdn.microsoft.com/en-us/library/microsoft.sharepoint.administration.spserverbinding.aspx

タイトル : SPIisSettings class
アドレス : https://msdn.microsoft.com/en-us/library/microsoft.sharepoint.administration.spiissettings.aspx

タイトル : SharePoint Server で PowerShell を使用する際の準備事項
アドレス : https://blogs.technet.microsoft.com/sharepoint_support/2013/10/04/sharepoint-server-powershell/

 

その他 : 代替アクセス マッピング (AAM) との違いについて

別の Web アプリケーション (. SharePoint – 8080) の代替アクセス マッピングに、80番ポートのアドレス (. http://www.sharepoint.com)を登録することでも、動作上同様の構成を実現できているように見えます。

hostheader5

しかし、上記の図に記載の通り IIS はポート番号で要求を振り分けています。その上で、80 番ポートのサイト内で処理が実行され、SharePoint のモジュールが代替アクセス マッピングのテーブルを参照して適切な Web サイトを探し出し、要求を対象の 8080 番ポートの Web サイトに転送します。そして、転送先の 8080 番の Web サイトが実際の処理を行います。

この構成は、双方の Web サイトに全ユーザーから毎回アクセスされる形となるため非効率です。IIS ログを確認すると、両方の Web サイトにログが記録されることが確認できます。

このような理由で、複数の Web アプリケーション間で同じポートを共有するよう構成するにあたり、ホストヘッダーではなく、代わりに代替アクセス マッピングを使うことは推奨しておりません。

それぞれの役割をあらためてまとめると以下のようになります。
・ホストヘッダーは、SharePoint Web フロント エンド サーバーに到達する HTTP を、各 IIS Web サイトに振り分けるための機能。
・代替アクセス マッピングは、Web アプリケーションが HTTP を受けるアドレスを管理する機能。

上記のように、別のものとして理解することが一般的となります。代替アクセス マッピングにつきましては、合わせて過去のブログ記事もご参考にしてください。

タイトル : 代替アクセス マッピングを理解する
アドレス : https://blogs.technet.microsoft.com/sharepoint_support/2015/09/15/4401/

以上の通りお伝えいたします。

2017 年 1 月の CU がリリースされました

$
0
0

2017 年 1 月の CU がリリースされました。

SharePoint 2016 向けの修正は 2 つリリースされており、それぞれ異なる修正のため、最新にするには両方インストールする必要があります。

SharePoint 2013

KB: January 10, 2017, cumulative update for SharePoint Server 2013 (KB3141481)

ダウンロード: Microsoft SharePoint Enterprise Server 2013 (KB3141481) の更新プログラム

SharePoint 2016

KB: MS17-002: Description of the security update for SharePoint Server 2016: January 10, 2017 (セキュリティ更新プログラムと同胞になります。)

ダウンロード: Microsoft SharePoint Enterprise Server 2016 (KB3141486) のセキュリティ更新プログラム

KB: January 10, 2017, update for SharePoint Server 2016 (KB3141487)

ダウンロード: Microsoft SharePoint Enterprise Server 2016 (KB3141487) の更新プログラム

 

– 参考リンク

January 2017 CU for SharePoint 2013 product family is available for download

https://blogs.technet.microsoft.com/stefan_gossner/2017/01/10/january-2017-cu-for-sharepoint-2013-product-family-is-available-for-download/

January 2017 CU for SharePoint Server 2016 is available for download

https://blogs.technet.microsoft.com/stefan_gossner/2017/01/10/january-2017-cu-for-sharepoint-server-2016-is-available-for-download/

 

– 注意事項

SharePoint 2013 2015 7 CU 以降の CU にはデータベーススキーマの拡張を行う修正が含まれており、CU 適用後に構成ウィザードを実行しない場合に検索クロールが失敗します。検索クロールの問題を回避するために、2015 7 CU より前の環境に 2015 7 CU 以降の CU を適用する際には、適用後に必ず構成ウィザードを実施してください。

Important: PSCONFIG is mandatory for July 2015 CU for SharePoint 2013

http://blogs.technet.com/b/stefan_gossner/archive/2015/07/15/important-psconfig-is-mandatory-for-july-2015-cu-for-sharepoint-2013.aspx

 

– サービスパック一覧

MOSS 2007 Service Pack 3 がリリースされました ※

https://blogs.technet.microsoft.com/sharepoint_support/2011/10/26/moss-2007-service-pack-3/

SPS2010 Service Pack 2 がリリースされました

https://blogs.technet.microsoft.com/sharepoint_support/2013/07/28/sps2010-service-pack-2/

SharePoint Server 2013 Service Pack 1 が再リリースされました

https://blogs.technet.microsoft.com/sharepoint_support/2014/04/23/sharepoint-server-2013-service-pack-1-3/

 

SharePoint Server 2007 Microsoft Windows SharePoint Services 3.0 は来年 2017 10 10 日に延長サポートフェーズが終了します。ご利用のお客様に置かれましては、ぜひ上位バージョンへのリプレースをご検討ください。

タイトル : Office 2007 approaching end of extended support

アドレス : https://support.microsoft.com/en-us/kb/3198497

アドレス : https://support.microsoft.com/ja-jp/kb/3198497

Project Online の PWA 上で編集できないフィールドについて

$
0
0

こんにちは、SharePoint サポートの森村です。
Project Online
Project Web App サイト (PWA サイト) 上にて、プロジェクトおよび、プロジェクト内のタスクの編集を行うことが可能ですが、一部のタスク フィールドについては PWA 上では表示のみとなり、編集をすることができません。
この場合は Project Professional 2016 上で PWA サイト上のプロジェクトを開き、編集をする必要があります。

例として、お問い合わせでよくいただく、上記に該当するフィールドは下記となります。

その他、フィールドではありませんが、統合プロジェクト (マスター プロジェクト) の作成、編集を行うためには Project Professional 2016 上で開く必要があります。

以上のように、ブラウザー上での操作ができない場合は、Project Professional 2016 上での編集をお願いいたします。

今回の投稿は以上です。


本情報の内容(添付文書、リンク先などを含む)は、作成日時点でのものであり、予告なく変更される場合があります。

OneDrive 同期クライアント (Windows 版) のプロファイル カスタマイズに対する制限事項のまとめ

$
0
0

こんにちは SharePoint サポートの森 健吾 (kenmori) です。

今回の投稿では、Windows 版の OneDrive 同期クライアント (OneDrive.exe) におけるプロファイルのカスタマイズの制限事項について記載します。

最初に結論から申しますと、OneDrive 同期クライアントは、移動ユーザー プロファイル、固定ユーザー プロファイル、一時プロファイルおよびコピー プロファイル (Sysprep による) には対応しておりません。

この制限については、一部の内容は以下サポート技術情報にも記載されております。

タイトル : 新しい OneDrive for Business 同期クライアントを使用してファイルおよびフォルダーを同期する際の制限事項
アドレス : https://support.microsoft.com/ja-jp/help/3125202/restrictions-and-limitations-when-you-sync-files-and-folders-using-the-new-onedrive-for-business-sync-client

抜粋
Windows のローミング プロファイル、固定プロファイル、および一時プロファイルはサポートされていません。ユーザー アカウントに対して OneDrive for Business アプリケーションのディレクトリへの上書きを許可しない設定では、One Drive for Business 同期アプリはサポートされていません。

エンタープライズ利用においては、管理者はクライアント端末のセットアップ・展開を大量に実施する必要があるため、これらの作業を計画的に行う必要があります。

しかし、これに対し Windows 10 で標準インストールされるようになった OneDrive 同期クライアント アプリケーションが、プロファイルのカスタマイズに対して制限事項があるということに気づかずに運用を開始し、問題に直面したという報告をよく受けます。

今回の投稿では、これらの制限事項について説明するとともに、問題発生時の暫定対処、および根本対処策の考察について記載いたします。

 

OneDrive 同期クライアントの展開について

OneDrive 同期クライアントの展開方法としては、Windows 10 でプレインストールされている状況と、OneDriveSetup.exe を使用してインストールする状況が想定されます。

どちらのインストール形式であったとしても、OneDrive 同期クライアントのインストールはユーザー単位のインストールとなります。

ファイルやレジストリは以下の箇所に格納されます。

ファイル : %localappdata%\Microsoft\OneDrive (*1)
レジストリ : HKEY_CURRENT_USER\SOFTWARE\Microsoft\OneDrive

レジストリには、このほかにもエクスプローラ (Shell) の拡張のために、HKEY_CLASSES_ROOT (つまり HKEY_CURRENT_USER\SOFTWARE\Classes) (*2) 配下に、いくつかの Shell 拡張オブジェクトが登録されます。

(補足 *1) : %localappdata% は、既定では C:\Users\{user_name}\AppData\Local になります。
(補足 *2) : HKEY_CLASSES_ROOT は、ローカル マシンの Classes (HKEY_LOCAL_MACHINE\SOFTWARE\Classes) と現在のユーザーの Classes (HKEY_CURRENT_USER\SOFTWARE\Classes) レジストリ キー配下をマージした結果を表示します。

前提として、OneDrive 同期クライアントは各ユーザーがインストールし、同期接続を構成することを想定したデザインとなっております。

このため、OneDrive 同期クライアントは、インストールされた絶対パス情報や各種設定情報をレジストリに多く保持する動作となり、これによってプロファイルのカスタマイズ設定に対し互換性を保てない要因となっています。これらの構成を自動化することもできません。

上記の前提をふまえて、これからシナリオ別に制限事項や対処策についてご説明します。

 

1. 移動ユーザー プロファイルの制限について

移動ユーザー プロファイルは、ユーザー プロファイルの情報をローカル ハードディスク上ではなく共有フォルダーなどのネットワーク領域に配置し、どのコンピューターでログオンしても別クライアント端末で行われたプロファイル変更を引き継げる設定となります。

しかし、移動ユーザー プロファイルの既定では、%localappdata% フォルダーがプロファイルとして保存される対象になっていません。プロファイルとして保存の除外対象となっているレジストリ値は以下の箇所に格納されています。

レジストリ
キー : HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Winlogon
 : ExcludeProfileDirs
 : AppData\Local;AppData\LocalLow;$Recycle.Bin;OneDrive;Work Folders

また、この設定を変更して、%localapdata% 配下のインストール ファイルや設定ファイルなどを引き継げたとしても、ログオン時にネットワーク共有に保存されたプロファイルからすべての同期された大量のファイル一式を含むプロファイルをロードする動作は問題となる場合が多いです。

 

対処策

上記の通り、移動プロファイルを使用する場合、OneDrive 同期クライアントをそもそも使用することができませんのでOneDrive 同期クライアントの実行を拒否することをお勧めします。

広範囲のクライアント端末に対し OneDrive 同期クライアント (OneDrive.exe) を使用させない方法として、グループ ポリシー エディターなどで、コンピューターの構成\Windows の設定\セキュリティの設定\アプリケーション制御ポリシー\AppLocker\実行可能ファイルの規則 などから OneDrive.exe の起動を禁止する方法が上げられます。

onedrive_profile1

2. 固定ユーザー プロファイル、一時プロファイルの制限について

固定ユーザー プロファイルの設定と、プロファイル ロード失敗時にロードされる一時プロファイルの状況下においては OneDrive 同期クライアントは正常動作しません。

これらの状況においては、設定変更や同期処理によって変更されたプロファイル (ファイルやレジストリ情報を含む) が保存できません。

OneDrive 同期構成による設定内容を保存できないため、再起動後には OneDrive 同期クライアントを使用することができません。

 

対処策

このシナリオにおいても、移動プロファイルの際と同様、AppLocker OneDrive 同期クライアントの実行を拒否する方法が有効と考えられます。

 

3. Sysprep 応答ファイルを利用したコピー プロファイルの制限について

コピー プロファイルは、各クライアント端末内で特定のユーザーのプロファイル情報をテンプレートとし、他ユーザーが新規ログオンした場合には、そのテンプレートを使用してプロファイルを生成する手法です。

コピー プロファイルを使用することで、一般的に以下のような要件を実現できます。

・プロファイル生成時間の短縮
・カスタム ユーザー アプリケーションの事前設定の横展開

しかし、この方法を使用すると、コピー元のプロファイル情報がそのままコピーされるため、OneDrive 同期クライアントの起動フォルダーの値が不正になります。

例えば、Administrator というユーザーでコピー元のプロファイルを生成した場合、レジストリ内のOneDrive 起動パスなど複数の箇所で C:\Users\Administrator\AppData\Local\Microsoft\OneDrive\OneDrive.exe などといった設定が格納されてしまいます。

これに対し、別のユーザーが起動した OneDrive.exe が、これらのキーを読み込んでファイル アクセスしたとしてもAdministratorユーザーのプロファイル配下へのファイル アクセスは拒否されますので、OneDrive.exe は正常動作することができません。

 

暫定対処

・exe を起動し上書きセットアップして、インストーラが書き込む設定値を上書き (修復) します。
・exe が起動後に書き込んだ細かな値 (特に Shell 拡張に関連する値) については、HKEY_CURRENT_USER\SOFTWARE\Classes 配下よりコピー元プロファイルのパス C:\Users\Administrator\AppData\Local\ などを検索して、見つけた値を手動で書き換えます。

(注意)
レジストリの値を正確なファイル パスに書き換えることで多くの場合動作するようになります。しかし、マイクロソフトはレジストリ エディター操作の過失操作によって生じた影響等について補償することはできません。編集に際しては細心の注意をはらって行ってくださいますようお願いいたします。

 

恒久対処案

OneDriveSetup.exe /uninstall を実行し、OneDrive をアンインストールした状態でコピー プロファイルを実施します。
・導入後に OneDrive を使用したいユーザーは、自分が使用する際に OneDriveSetup.exe をインターネットからダウンロードしてインストールし、使用します。

 

 

 

 

SharePoint Online/OneDrive for Business の .zip ファイルの文字化けについて

$
0
0

こんにちは。SharePoint サポートの井上です。

先日 SharePoint Online/OneDrive for Business で複数のファイル、またはフォルダを .zip ファイルでまとめてダウンロードする機能が追加されました。

 

タイトル : Download files and folders from OneDrive or SharePoint

アドレス : https://support.office.com/en-us/article/5c7397b7-19c7-4893-84fe-d02e8fa5df05

 

本機能でダウンロードした .zip ファイルを展開すると、以下の条件に一致する場合にファイル名が文字化けする動作が報告されており、本投稿にてご案内いたします。

 

1. UTF-8 に対応していない zip 展開ソフトをご利用されている

SharePoint Online/OneDrive for Business は、zip ファイルに含めるファイル名を UTF-8 でエンコードするため、ファイルの展開に使用するツールが UTF-8 に対応していない場合、ファイル名が文字化けする現象が発生いたします。

 

SharePoint Online/OneDrive for Business は様々な利用環境、言語で使用されることが想定されているため、利用環境や言語に影響を受けにくい様に文字コードに UTF-8 が使用されております。サーバー側で文字コードを変更する方法は提供しておりません。

 

このため、SharePoint Online/OneDrive for Business からダウンロードされた zip ファイルを展開する際には、Windows の標準機能で展開いただくか、UTF-8 に対応している展開ソフトをご利用ください。

 

2. KB2704299 が適用されていない Windows 7 端末で、Windows 標準の展開ツールを使用

Windows 7 標準の .zip 展開機能が UTF-8 に対応していないため、文字化けが発生する現象が報告されておりますが、以下の修正プログラムにより修正が行われております。

Windows 7 の標準機能で .zip ファイルを展開した際に文字化けが発生する場合は、以下の更新プログラムの適用をご検討ください。

 

タイトル : Japanese characters in file names are displayed as garbled text after you decompress a .zip file in Windows 7 or in Windows Server 2008 R2

アドレス : https://support.microsoft.com/help/2704299

 

 

なお、 Windows 8 以降の Windows OS については既に修正が組み込まれているため、Windows 標準機能で SharePoint Online/OneDrive for Business からダウンロードした .zip ファイルを展開した際に文字化けは発生いたしません。

 

 

 

今回の投稿は以上です。

本情報の内容は、作成日時点でのものであり、予告なく変更される場合があります。

SharePoint Online と連携するカスタム アプリケーションでエラー ログに残すべき必須情報

$
0
0

こんにちは SharePoint サポートの森 健吾 (kenmori) です。

今回の投稿では、SharePoint Online および OneDrive for Business と連携するカスタム アプリケーションで、エラーが発生した際にログに含めるべき情報についてご紹介します。

 

関連付け ID について

SharePoint Online や OneDrive for Business に対して CSOM や REST API を呼び出すアプリケーションにおいては、問題が発生した際のトラブルシューティングのために、エラー発生時の関連付け ID が必要になります。このため、カスタム アプリケーション側でもこの関連付け ID をログに残す必要があります。

ブラウザからアクセスする通常の利用シナリオにおいても、Fiddler IE 開発者ツールなどで HTTP トレースを採取し、応答ヘッダーから SPRequestGUID 値を確認することがありますが、API を使用した場合においても有効な方法となります。

弊社サポートで調査を行う際には、この関連付け ID から現象発生時のサーバー側のログを確認します。なお、ログの保持期間はとても短いため (通常は約1日程度)、現象発生後なるべくお早めにお問い合わせください。

 

概要

上記ご説明をふまえ、一般的に調査を実施する上で必要な情報は以下になります。
詳細な説明は後記いたします。

1. 現象が発生した日付と時刻
2. エラー メッセージ
3. 呼び出し先 URL
4. HTTP ステータス コード
5. 関連付け ID (Correlation ID)

 

サンプル コード

上記情報を採取するためのサンプル コード (C#) を以下にご紹介します。

下記サンプルの通り、CSOM とREST いずれにおいても、ログ出力に必要な情報は、例外オブジェクトを WebException にキャストし、応答 (Response) 内容を解析して集める方法が効率的です。

下記は最小構成のサンプル コードとなりますが、ディスク容量を考慮しない場合は、すべての HTTP 応答ヘッダーを残していただくとさらに有効です。

using を以下のように追加します。

using System.Net;
using System.Text;
using SP = Microsoft.SharePoint.Client;

以下は例外情報を解析するメソッド GetExceptionDetail 呼び出し元部分です。 

        private void RunCSOMorREST()
        {
            try
            {
                // CSOM または REST API の呼び出し
            }
            catch (Exception ex)
            {
                string ErrorText = GetExceptionDetail(ex);

            }
        }

以下は、例外オブジェクトからデータを実際に取得するメソッド部分の実装です。

        private string GetExceptionDetail(Exception ex)
        {
            StringBuilder errorText = new StringBuilder();
            // エラー メッセージ
            errorText.Append(ex.Message);
            if (ex is WebException)
            {
                WebException wex = ex as WebException;
                if (wex.Response != null)
                {
                    HttpWebResponse response = (HttpWebResponse)wex.Response;
                    errorText.Append("\t");
                    // 呼び出し先 URL
                    errorText.Append(response.ResponseUri.ToString());
                    errorText.Append("\t");
                    // HTTP ステータス コード
                    errorText.Append(response.StatusCode);
                    errorText.Append("\t");
                    // 関連付け ID (Correlation ID)
                    errorText.Append(response.Headers["SPRequestGuid"]);
                }
            }
            return errorText.ToString();
        }
 

 

詳細説明

上記サンプル コードで取得している情報について詳細を記載いたします。

 

1. 現象が発生した日付と時刻

エラーが発生した日時の情報は、カスタム アプリケーション側でエラーに直面した際の情報と関連付けを行うにあたり非常に重要です。

サンプル コード内では日時データを採取しておりませんが、DateTime.Now.ToString() などで構いませんのでログ取得を実施ください。

なお、SharePoint Online においては、データセンター側のログ保存期間もありますため、現象発生後期間が経過しているかどうかを確認する上で重要となります。

現象発生から 1 日以上経過している場合などにおいてはログ調査できない可能性があります。現象発生時には、なるべく早くご連絡ください。

 

2. エラー メッセージ

エラー メッセージは、エラー発生内容の概要を確認するために重要となります。

エラーの種類 (Exception の型) を問わず取得できるため、必ず取得しておく必要があります。

 

3. 呼び出し先 URL

特にマルチテナントに対してサービスを提供するアプリケーションでは、アプリケーション側で失敗したログが、どのテナントに対する処理であったかを区別する必要があります。

呼び出し先 URL のホスト部分には、ホスト URL が含まれますので調査に有効な情報となります。

 

4. HTTP ステータス コード

上記 2. で取得しているエラーメッセージには同様の情報が含まれる可能性があります。しかし、念のため HTTP ステータス コードはエラーの種類を特定するために有効です。

 

5. 関連付け ID (Correlation ID)

データセンター側のログを確認する上で、最も重要な情報となります。

関連付け ID (Correlation ID) は、すべての HTTP 要求に対して採番される GUID 型の一意なデータであり、HTTP 応答ヘッダーに以下のように記載されます。

SPRequestGuid: 7e12d79d-60a7-3000-0090-fe30bacd1132

この情報は発生現象のログと照合するために必須の情報となります。

 

参考 : ClientContext.TraceCorrelationId プロパティについて

ClientContext.TraceCorrelationId は関連付け ID を返すプロパティですが、現時点では残念ながら例外発生時には null を返す動作であることを確認しています。

ClientContext.TraceCorrelationIdプロパティを使用せず、上記サンプルを代替でご使用ください。

タイトル : ClientRuntimeContext.TraceCorrelationId property
アドレス : https://msdn.microsoft.com/en-us/library/office/jj168853.aspx

なお、ClientContext.TraceCorrelationId プロパティに関する動作は、作成日時点でのものであり、予告なく変更される場合があります。 


Project Professional 2016 から Project Online の PWA サイトへの接続時にエラーとなる場合について

$
0
0

こんにちは、SharePoint サポートの森村です。
Project Professional 2016
クライアントから、Project Online Project Web App サイト (PWA サイト) への接続時にエラーとなる場合のトラブルシュート方法として、以前に下記のブログ記事で関連情報をご案内しております。

タイトル : SharePoint Online/Project Online Project Professional 2016/2013 製品の連携時のトラブルシュート方法について
アドレス : https://blogs.technet.microsoft.com/sharepoint_support/2015/12/17/sharepoint-onlineproject-online-project-professional-20162013-26041

上記ブログ記事の方法でも現象が改善しない場合は、本ブログ記事の手順を追加で実施いただくことで現象が改善する場合がありますので、お試しいただければと思います。

事前準備

上記ブログ記事1-1. から 1-4. および 2-1.2-2. の手順の実施をあらかじめ行います。

対処方法手順

下記の手順を順番に実施します。

  1. Office 2016 製品からのサインアウトの実施
  2. Office 2016 のレジストリの削除
  3. Windows の資格情報の削除
  4. PC の再起動
  5. PWA サイトへのアクセスの実施

a. Office 2016 製品からのサインアウトの実施
サインアウトを実施し、Office 2016 製品に保存されているサインイン情報を削除します。

  1. 現象が発生している PC 上にて、Project Professional 2016 を含む、すべての Office 2016 アプリケーションを終了します。
  2. Project Professional 2016 を起動します。
  3. 右上のユーザー名をクリックして、[アカウントの切り替え] から、すべてのアカウントにて [サインアウト] を実施します。
  4. Project Professional 2016 を終了します。

b. Office 2016 のレジストリの削除
サインアウト実施後に、レジストリ上に残っている Office 2016 のサインイン情報を削除します。

  1. 該当 PC にて、すべての Office 2016 製品が起動していないことを確かめます。
  2. レジストリ エディターを起動します。
  3. [コンピューター]-[HKEY_CURRENT_USER]-[Software]-[Microsoft]-[Office]-[16.0]-[Common]-[Identity]-[Identities] と展開します。
  4. [Identities] のキー上で右クリックし、メニューから [エクスポート] を選択します。
  5. 適切な名前を作成し、レジストリ情報のバックアップを作成します。
  6. [Identities] のキー配下に、数字で始まるキー、メールアドレスのようなキー、等、複数のキーが存在している場合は、配下のキーそれぞれを選択して右クリックし、メニューから [削除] を選択します。
  7. 6. の手順を繰り返し、[Identities] の配下に存在していたキーをすべて削除します。

c. Windows の資格情報の削除
Windows OS 上に保存されている Office 2016 関連の資格情報を削除します。

  1. [コントロール パネル] – [ユーザー アカウント] – [資格情報マネージャー] を開きます。
  2. [Windows 資格情報] をクリックします。
  3. [汎用資格情報の一覧] の中より、“Microsoft Office 16_Data: orgid: ****@****” から始まる資格情報をすべて削除します。

d. PC の再起動
a. b. c. の変更を反映させるために、該当の PC の再起動を実施します。

e. PWA サイトへのアクセスの実施
Office 365
に「サインインしたままにする」のオプションを使用してサインインして PWA サイトを表示後に、Project Professional 2016 から PWA サイトへの接続を実施し、現象が改善しているかどうかを確認します。

今回の投稿は以上です。


本情報の内容(添付文書、リンク先などを含む)は、作成日時点でのものであり、予告なく変更される場合があります。

SharePoint Server 2016 開発ツールがリリースされました

$
0
0

こんにちは SharePoint サポートの森 健吾 (kenmori) です。

US 時間の 2017 3 7 日に Visual Studio 2017 がリリースされました。

この Visual Studio 2017 に含まれる Office Developer Tools for Visual Studio には、SharePoint Server 2016 のプロジェクト テンプレートが含まれておりますので、SharePoint 2016 で開発を行うためのテンプレートとツールも正式にリリースされたことになります。

タイトル : Visual Studio | Developer Tools for Services | Microsoft IDE
アドレス : https://www.visualstudio.com/ja/

タイトル : Announcing Visual Studio 2017 General Availability… and more
アドレス : https://blogs.msdn.microsoft.com/visualstudio/2017/03/07/announcing-visual-studio-2017-general-availability-and-more/

Office Developer Tools for Visual Studio Professional/Enterprise Edition 双方に対応しております。

以下は、Visual Studio インストーラーの画面キャプチャとなります。SharePoint Server 2016 の開発を行う場合は、[ワークロード] タブより Office/SharePoint 開発を選択してインストールしてください。

vs20171

インストール後、新しいプロジェクトを作成すると以下のように SharePoint 2016 のプロジェクト テンプレートが使用できるようになります。

vs20172

注意

以前に Visual Studio 2015 用の Office Developer Tools Preview2 がリリースされております。
こちらは Preview 版となりますので、本運用を想定したソリューション開発は実施しないようお願いいたします。

タイトル : Microsoft Office Developer Tools Preview 2 for Visual Studio 2015
アドレス : http://www.microsoft.com/en-us/download/details.aspx?id=51683

タイトル : The Latest of Microsoft Office Developer Tools: Office Add-in Commands and SharePoint 2016 Support
アドレス : https://blogs.msdn.microsoft.com/visualstudio/2016/04/26/the-latest-of-microsoft-office-developer-tools-office-add-in-commands-and-sharepoint-2016-support/

また、現在のところ、Visual Studio 2015 用の Office Developer Tools のリリース予定に関する情報はございません。
そのため、SharePoint Server 2016 のソリューション開発では、Visual Studio 2017 をご利用ください。

 

Yammer グループと Office 365 グループの統合について

$
0
0

こんにちは、SharePoint サポート チームの関 友香です。

 

先日 (2017 3 2 ) Yammer グループと Office 365 グループが統合されることが公式ブログより告知されました。サポート記事でもご案内差し上げております通り、要件を満たしたテナントをご利用の場合には、この機能をすでに確認された方もいらっしゃるかと思います。今回の投稿では、Yammer グループと Office 365 グループとの統合について、サポート窓口にお問い合わせいただく以下の疑問についてお答えいたします。

・ Yammer グループの作成を制限する方法はないのか。

Office 365 グループに統合されることでとグループやチームサイトの管理が煩雑になることを懸念している。統合を制限する方法はないのか。

 

Yammer グループの作成と Office 365 グループの統合について
Yammer はすべてのユーザーがグループに参加し、利用者同士がつながりを持つことができる企業向けのソーシャル ネットワーキング サービスとなります。そのため、すべてのユーザーが Yammer 上で自由にグループを作成することができ、管理者側がグループの作成を制御することはできません。

Office 365 グループとの統合により、新しく作成された Yammer グループに紐づく Office 365 グループが自動的に作成されることとなり、Office 365 Yammer 間で統合された機能をスムーズに利用できる反面、すべての Yammer グループが Office 365 グループに統合されてしまうのは困るという管理者様もいらっしゃるのではないかと思います。 そのような場合には、Office 365 グループの作成を制限することで、Yammer から Office 365 に統合されるグループを制限することができます。

 

Office 365 グループの作成を制限する方法

Office 365 グループの作成の制限する方法は、「(A) テナント単位で無効とする」、または 「(B) 特定のセキュリティ グループのメンバーのみ作成を許可する」の 2 通りの方法がございます。全体管理者は 2 通りの方法のどちらか片方の方法にて、Office 365 グループの作成を制限することが可能です。設定時の動作を以下に簡単にご説明いたします。また、設定手順は後述させていただきます。

 

(A) テナント単位で Office 365 グループの作成を無効とした場合 

Yammer で作成したグループは Office 365 側には連携されず、Yammer グループに紐づく Office 365 グループは作成されません。

Office 365 グループ作成の制限は Yammer 上でのグループ作成には影響を及ぼしませんので、すべてのユーザーは引き続き Yammer 上でグループを作成することが可能です。

 

(B) 特定のセキュリティ グループのメンバーのみ Office 365 グループの作成を制限している場合 

・ユーザーが Office 365 グループの作成を許可されたセキュリティ グループのメンバーである場合には、ユーザーが Yammer 上で作成したグループと連携した Office 365 グループが Office 365 上でも作成されます。

・ユーザーが Office 365 グループの作成を許可されたセキュリティ グループのメンバーでない場合には、ユーザーは Yammer 上で引き続きグループを作成することは可能ですが、Yammer グループと連携した Office 365 グループは作成されません。

Office 365 グループ作成の制限は Yammer 上でのグループ作成には影響を及ぼしませんので、すべてのユーザーは引き続き Yammer 上でグループを作成することが可能です。


設定手順

以下に記載いたします Office 365 グループの作成を制限する方法は、公開情報 “Manage Office 365 Group Creation (英語のみ) をもとに作成しております。

なお、Office 365 グループは Yammer 以外の様々な Office 365 上のサービスでも利用されておりますので、本設定を適用される際には各サービスの管理者様と設定内容について十分にご検討ください。

いずれの設定におきましても、反映までに 5 ~ 15 分程度かかることがございます。

 

– 事前準備 –

(1-1) 64 Bit OS が動作している Windows 10/8.1/8/7 PC を用意します。あるいは、Windows Server 2012 R2/Windows Server 2012/Windows Server 2008 R2 のサーバー PC を用意します。

(1-2) Windows 7 PC、あるいは Windows Server 2008 R2 のサーバー PC を用意する場合は、前提条件を満たすために、最新の Windows Update をすべて適用します。Windows Update 適用後に再起動を行い、その後下記リンクから Windows Management Framework 3.0 をインストールし、 Windows PowerShell 3.0 を使用可能とします。(Windows 8Windows Server 2012 以降の場合は本手順は不要です。)

・Windows Management Framework 3.0

 https://www.microsoft.com/en-us/download/details.aspx?id=34595

– 補足

32 bit OS については、以下の公開情報に記載の通り、Windows PowerShell Windows Azure Active Directory モジュールはサポートしておりませんので予めご注意ください。

・Azure AD モジュールのインストール

https://msdn.microsoft.com/ja-jp/library/jj151815.aspx?f=255&MSPPError=-2147217396#bkmk_installmodule

—– ここから抜粋 —–

2014 年 10 20 日をもって、Azure Active Directory Module for Windows PowerShell (32 ビット バージョン) は廃止されます。32 ビット版のサポートはこれ以上行われず、Azure Active Directory Module の今後の更新は 64 ビット版についてのみリリースされます。将来のサポートと互換性のため、64 ビット版をインストールすることを強くお勧めします。

—– ここまで抜粋 —–

 

(2) 設定時に使用するWindows PowerShell Windows Azure Active Directory モジュール に必要な下記をインストールしてください。

IT プロフェッショナル 用 Microsoft Online Services サインイン アシスタント RTW

https://www.microsoft.com/ja-jp/download/details.aspx?id=41950

AdministrationConfig-V1.1.130.0-Preview.msi

http://connect.microsoft.com/site1164/Downloads/DownloadDetails.aspx?DownloadID=59185

下図の通り、Preview のインストールが必要となります。

a

(3) (B) の設定を行う場合には、Office 365 グループの作成を許可するセキュリティ グループをご用意ください。

 

– 設定手順 –

(A) テナント単位で Office 365 グループの作成を制限する

1. Windows Azure Active Directory Module for Windows PowerShell を起動し、下記のコマンドを実行します。

Connect-MsolService

2. [アカウントにサインイン] 画面にテナントの全体管理者の資格情報を入力し、[サインイン] をクリックします。

3. 下記のコマンドを実行し、現在の設定情報を表示します。

Get-MsolCompanyInformation

4. “UsersPermissiontoCreateGroupsEnabled” の設定値を確認します。この設定が “True” の場合、テナント上で Office 365 グループの作成が可能な状態となります。

5. Office 365 グループの作成を無効とする場合には、下記のコマンドを実行します。

Set-MsolCompanySettings -UsersPermissiontoCreateGroupsEnabled $false

6. 下記のコマンドを実行し、設定が変更されているかを確認します。

Get-MsolCompanyInformation

 

– 補足

2017 3 10 日時点の動作では、上記の設定にて全体管理者とユーザー管理の管理者は Yammer グループに紐づく Office 365 グループを作成することが可能です。

・ (B) の設定を行う場合には、UsersPermissiontoCreateGroupsEnabled は “True” である必要がございます。

 

(B) セキュリティ グループ単位で Office 365 グループの作成を制限する

1. Windows Azure Active Directory Module for Windows PowerShell を起動し、下記のコマンドを実行します。

Connect-MsolService

2. [アカウントにサインイン] 画面にテナントの全体管理者の資格情報を入力し、[サインイン] をクリックします。

3. 下記のコマンドを実行し、現在の設定情報を表示します。

Get-MsolCompanyInformation

4. “UsersPermissiontoCreateGroupsEnabled” の設定値が “True” であることを確認します。

5. 下記のコマンドを実行し、セキュリティ グループの Object ID を確認します。

Get-MsolGroup -SearchString “<セキュリティ グループ名>”

(例) Get-MsolGroup -SearchString “AllowedtoCreateGroups”

6. コマンドの実行結果に表示される Object ID をメモしておきます。

7. 下記のコマンドを実行し、グループ設定テンプレートを取得します。

$template = Get-MsolAllSettingTemplate | where-object {$_.displayname -eq “Group.Unified”}

※ なお、Get-MsolSettingTemplate にてエラーとなる場合は、プレビュー版の Azure Active Directory PowerShell モジュールをインストールしていないことが原因として考えられます。上記 「事前準備」 の手順 (2) を再度ご確認ください。

8. 下記のコマンドを実行し、グループ設定テンプレートの設定情報を取得します。

$setting = $template.CreateSettingsObject()

9. 下記のコマンドを実行し、現在の設定値を確認します。

$setting.Values

10. 下記のコマンドを実行し、Office 365 ユーザーによる Office 365 グループの作成を無効化します。

$setting[“EnableGroupCreation”] = “false”

11. 下記のコマンドを実行し、特定のセキュリティ グループによる Office 365 グループの作成を許可します。Object ID には手順 5 でメモした Object ID を指定します。

$setting[“GroupCreationAllowedGroupId”] = “<object ID>”

(例) $setting[“GroupCreationAllowedGroupId”] = “7e5ba3a7-efae-4002-9b39-5af47205bc83”

12. 下記のコマンドを実行し、設定を適用します。この際に設定用オブジェクトが作成されますので、設定変更を行いたい場合には、このオブジェクト ID を使用することになります。

New-MsolSettings -SettingsObject $setting

13. 下記のコマンドを実行し、設定が変更されたことを確認します。

$setting.Values

 

– 補足

2017 3 10 日時点の動作では、上記の設定にて許可したセキュリティ グループのメンバーおよび全体管理者とユーザー管理の管理者は Yammer グループに紐づく Office 365 グループを作成することが可能です。

2017 3 10 日時点の動作では、上記の設定にて許可したセキュリティ グループのメンバーに含まれていない全体管理者は、Office 365 管理センターの [グループ] メニューから Office 365 グループを作成することが可能ですが、Outlook on the Web 等の Office 365 グループの UI 上からは Office 365 グループを作成することはできません。

2017 3 10 日時点の動作では、上記の設定にて許可したセキュリティ グループのメンバーに含まれていないユーザー管理の管理者は、Office 365 管理センターの [グループ] メニューからセキュリティ グループのみ作成が可能ですが、Outlook on the Web 等の Office 365 グループの UI 上からは Office 365 グループを作成することはできません。

・ 指定できるセキュリティ グループは 1 つのみですが、Office 365 管理センターで、指定したグループに複数のセキュリティ グループを入れ子にすることが可能です。

・ 一度設定したセキュリティ グループを変更する場合は、以下の「(B) 設定したセキュリティ グループを変更する」 をご実施ください。

 

(B) 設定したセキュリティ グループを変更する

1. Windows Azure Active Directory Module for Windows PowerShell を起動し、下記のコマンドを実行します。

Connect-MsolService

2. [アカウントにサインイン] 画面にテナントの全体管理者の資格情報を入力し、[サインイン] をクリックします。

3. 下記のコマンドを実行し、現在の設定情報を表示します。

Get-msolallsettings

4. コマンドの実行結果に表示される Object ID をメモしておきます。

5. 下記のコマンドを実行します。Object ID には手順 4 でメモした Object ID を確認します。

$setting=Get-MsolSettings -SettingId <ObjectId>

(例) $setting=Get-MsolSettings -SettingId a032f8a5-301d-4605-a0ad-6b9080df1055

6. 下記のコマンドを実行し、現在の設定値を確認します。

$setting.values

7. 下記のコマンドを実行し、現在の設定値を取得します。

$value=$setting.GetSettingsValue()

8. 下記のコマンドを実行し、変更後のセキュリティ グループの Object ID を確認します。

Get-MsolGroup -SearchString “<セキュリティ グループ名>”

(例) Get-MsolGroup -SearchString “AllowedtoCreateGroups”

9. コマンドの実行結果に表示される Object ID をメモしておきます。

10. 下記のコマンドを実行し、現在設定しているセキュリティ グループを変更します。Object ID には手順 9 でメモした Object ID を指定します。

$value[“GroupCreationAllowedGroupId”] = “<object ID for the new group>”

(例) $value[“GroupCreationAllowedGroupId”] = “3054dce3-37e6-437a-a817-2363272cac1c”

11. 下記のコマンドを実行し、設定を適用します。Object ID には手順 4 でメモした Object ID を確認します。

Set-MsolSettings -SettingId <ObjectId of the settings object> -SettingsValue $value

(例) Set-MsolSettings -SettingId a032f8a5-301d-4605-a0ad-6b9080df1055 -SettingsValue $value

12. 下記のコマンドを実行し、設定が変更されたことを確認します。

$setting.Values

 

[参考情報]

タイトル : Yammer integration with Office 365 Groups now rolling out

アドレス : https://blogs.office.com/2017/03/02/yammer-integration-with-office-365-groups-now-rolling-out/

タイトル : Office 365 グループと Yammer の統合のロールアウトを開始

アドレス : https://blogs.technet.microsoft.com/microsoft_office_/2017/03/07/yammer-integration-with-office-365-groups-now-rolling-out/

タイトル : Yammer Office 365 グループ

アドレス : https://support.office.com/ja-jp/article/d8c239dc-a48b-47ab-b85e-6b4b8191a869

タイトル : Manage Office 365 Group Creation

アドレス : https://support.office.com/ja-jp/article/Manage-Office-365-Group-Creation-4c46c8cb-17d0-44b5-9776-005fced8e618

 

今回の投稿は以上になります。

本情報の内容は、作成日時点でのものであり、予告なく変更される場合があります。

 

SharePoint 診断ログを使用したトラブルシュート

$
0
0

こんにちは、SharePoint サポートの西村です。

今回は SharePoint 診断ログの採取方法と、ログを使用したトラブルシュート方法について投稿します。

 

我々サポートチームにトラブルシュートのお問い合わせをいただいた際、ほとんどの場合 SharePoint 診断ログのご提供を依頼させていただいております。

診断ログを確認することで、問題の原因特定に大変有効となりますので、本投稿を運用の参考としていただければ幸いです。

 

  1. 診断ログについて
  2. ログレベルについて
  3. ログの解析について

 

  1. 診断ログについて

診断ログは既定では SharePoint のインストール フォルダ配下の Logs フォルダに出力され、14 日ごとにローテーションされて古いログは自動的に破棄されます。

ログの出力先、および保存日数は SharePoint の全体管理サイト ([監視] – [レポート] – [診断ログの構成]) で変更することが可能です。

サポートにお問い合わせいただく際、現象発生から時間が経っているとログが既に破棄されてしまっている場合もありますので、ご注意いただければと思います。

1

 

 

– 参考情報

タイトル:SharePoint Server 2016 で診断ログを構成する

アドレス:https://technet.microsoft.com/ja-jp/library/ee748656(v=office.16).aspx

 

  1. ログレベルについて

現象のトラブルシュートを行う際には、ログレベルを詳細に変更することが有効です。

なおログレベルを上げるほど、ログの出力量は比例して増加するため、ディスク容量やリソースをより多く使用することになります。

上述の技術資料にも記載がありますが、トラブルシュートや特定の処理の記録を目的とする以外で、平時より詳細なログレベルで運用いただくことは推奨されませんのでご留意ください。

 

SharePoint 管理シェルを管理者権限で起動し、下記のコマンドレットを実行することでログレベルの変更が可能です。

>Set-SPLogLevel -TraceSeverity Verbose

2

なお、SharePoint 2010 以降では下記のコマンドレットを実行することで、さらに詳細なログを出力することも可能です。

現象の発生が短時間であり、より詳細に処理内容を確認したい場合に有効です。

>Set-SPLogLevel -TraceSeverity VerboseEx

 

既定のログレベルに戻す場合には、下記のコマンドレットを実行します。

> Clear-SPLogLevel

 

※カテゴリごとにログの出力レベルを変更している場合には、上記コマンドによってすべて既定値に変更されますので、個別に再設定いただく必要があります。

現在のすべてのカテゴリのログレベルを出力するには、下記コマンドレットが有効です。

 

>Get-SPLogLevel | Out-GridView

3

– 参考情報

タイトル:Set-SPLogLevel

アドレス:https://technet.microsoft.com/ja-jp/library/ff607887.aspx

 

タイトル:Clear-SPLogLevel

アドレス:https://technet.microsoft.com/ja-jp/library/ff607880.aspx

 

タイトル:Get-SPLogLevel

アドレス:https://technet.microsoft.com/ja-jp/library/ff607576.aspx

 

 

  1. ログの解析について

詳細レベルのログ ファイルはサイズが大きくなりますので、現象が再現できる場合には再現時にログ ファイルを切り替えることで、解析がしやすくなります。

既定では 30 分ごとにログ ファイルが自動的に切り替わりますが、現象発生前後で下記のコマンドレットを実行することで、ログ ファイルの切り替えを手動で行うことが可能です。

 

>New-SPLogFile

4

さて、詳細レベルのログが採取できたら、解析をしてみましょう。

診断ログは一般的なテキスト エディタで開けますので、誰でも確認することが可能ですが、下記のツール等を使用することでより見やすくなるかと思います。

 

タイトル:ULS Viewer

アドレス:https://www.microsoft.com/en-us/download/details.aspx?id=44020

 

今回は一例として、サイト アクセス時に発生した予期しないエラーのトラブルシュートを行ってみたいと思います。

SharePoint のエラーとして予期しないエラーはエラーの中で最も一般的なメッセージですが、これだけでは原因の特定が困難かと思います。

しかしエラー画面には他にも有効な情報がありますので、是非画面ショットを取得してください。

確認するのは関連付け ID と日付と時刻です。”技術的な詳細” リンクをクリックすると表示されます。

5

 

特定の処理に関連するログは関連付け ID によって紐づけられます。

この ID をもとにログを確認することで、膨大なログの中から目的とする処理のログのみを抽出することができます。

ではさっそく ULS Viewer でログを開いて、上記関連付け ID のログを確認してみましょう。

6

 

今回はサイト アクセス時のエラーについて確認をしたいので、w3wp.exe の処理を確認すれば良いのですが、このままだと msseach.exe 等ほかのプロセスの処理も羅列されているので、少々煩雑です。

そこで関連付け ID (Correlation) でフィルターします。(関連付け ID が分からない場合は、プロセスやカテゴリなどでフィルターすると良いかと思います。)

7

大分整理できました。

今回はエラーなので、更に絞り込んでみましょう。上部の赤いボタン以外の選択を解除することで、Monitorable 以上のレベルのログのみ表示することが可能です。

8

タイムアウトが発生していることが確認できました。

一時的かもしれませんし、IIS のタイムアウト値を延長する等、対応が必要かもしれませんが、対処法が見えてきたかと思います。

9

 

エラーの確認はもちろん、現象発生時の処理の詳細を確認することや、SQL Server に対して実行するストアドプロシージャ、クエリの特定等にも診断ログは有効です。

ご利用環境に何らかの問題が発生した時の確認にお役立ていただければ幸いです。

また、ログを見ても全然わからない!という場合は、弊社サポートチームまでご相談いただければ全力でご支援いたしますので、是非ご相談ください!

サイト コレクションの使用済み記憶域サイズについて (Online/オンプレミス)

$
0
0

こんにちは。SharePoint サポートの井上です。

サイト コレクションの使用済み記憶域サイズが、サイト コレクションの記憶域メトリックスページで確認できる合計サイズの総和と大きく異なる場合がございます。

 

以下の記憶域メトリックスページの例では、サイト コレクションの使用済み記憶域サイズが約 10 GB になりますが、合計サイズの総和は約 2 MB となり、それぞれが示す値が大きく異なることがご確認いただけます。

img

 

 

サイト コレクションの使用済み記憶域サイズの動作について

サイト コレクションの使用済み記憶域には、ごみ箱に存在するサイトやファイルも含まれますが、記憶域メトリックスページにはごみ箱の情報が含まれないため、上述の様な状況は発生しうる動作となります。

このため、同様の現象を確認された場合は、初めにごみ箱にサイトやファイルが存在しないかをご確認ください。

ごみ箱のアイテムは、一定期間を経過後に自動で削除されますが、サイト コレクションの使用済み記憶域のサイズがクォータ制限を超過する可能性を確認された際には、ごみ箱からアイテムを手動で削除することをご検討ください。

 

なお、見落としやすい動作として、ごみ箱にはサイト コレクションの管理者のみがアクセスできる、第 2 段階のごみ箱が存在します。

一般の利用者がごみ箱からアイテム削除すると、該当のアイテムは第 2 段階のごみ箱に移動しますが完全には削除されませんので、サイト コレクションの使用済み記憶域から該当のアイテムのサイズが開放されません。

サイト コレクションの使用済み記憶域から手動で開放するためには、サイト コレクションの管理者にて第 2 段階のごみ箱からアイテムを削除します。

 

ごみ箱の動作の詳細については、以下の公開情報をご確認ください。

タイトル : サイト コレクションのごみ箱から、削除したアイテムを復元する

アドレス : https://support.office.com/ja-jp/article/5fa924ee-16d7-487b-9a0a-021b9062d14b

 

上記の動作は、SharePoint Online、オンプレミス共に同様になります。

 

今回の投稿は以上です。

本情報の内容は、作成日時点でのものであり、予告なく変更される場合があります。

FAST ESP の SAM 証明書が日本時間 2017/3/17 (金) 22:00 時に有効期限切れて検索できない事象について

$
0
0

こんにちは。SharePoint & FAST サポートの銭 (kusen) です。

FAST ESP の SAM 証明書が 2017/3/17 () 22:00 で有効期限が切れて検索できない事象について、お客様からお問い合わせをいただいております。

今回は当該事象について説明したいと思います。

 

<目次>

  1. 事象
  2. 原因
  3. 回避策

 

1 事象

=========

日本時間 2017 3 17 () の夜間 22:00 時以降に、Security Access Module (以降は SAM と記載) モジュールが入っている FAST ESP の環境では、検索結果に 0 件が表示される事象が発生しました。

また、Admin GUI から以下のような ERROR ログが記録されます。

 

[2017-03-18 00:49:00]   ERROR   qrserver   fastespserver.contoso.com   15100   systemmsg   FastQT_Security: Security QT couldn’t expand uid [SPS:A9904012] (FDSSMAPI call failed)

[2017-03-18 00:49:00]   ERROR   qrserver   fastespserver.contoso.com   15100   systemmsg   FastQT_Security: Security QT – Group Expansion failed for user id &quot;SPS:A9904012&quot;. API error: {Failed to initialize FDSSMAPI SSL initialization failed: missing or invalid certificate? file: C:\esp\etc/FDSSM_client.pem FDSSMAPI call (GetGroupExpansionFilter) aborted, FDSSMAPI not initialized }

[2017-03-18 00:48:20]   ERROR   qrserver   fastespserver.contoso.com   15100   systemmsg   FastQT_Security: Failed to initialize FDSSMAPI: SSL initialization failed: missing or invalid certificate? file: C:\esp\etc/FDSSM_client.pem

[2017-03-18 00:48:20]   WARNING   qrserver   fastespserver.contoso.com   15100   systemmsg   FastQT_Security: SSL Init (SSL client): Certificate in C:\esp\etc/FDSSM_client.pem expires at 2017-03-17 13:00 UTC

[2017-03-18 00:48:20]   ERROR   qrserver   fastespserver.contoso.com   15100   systemmsg   FastQT_Security: SSL Init: CA certificate at level 1: certificate has expired

[2017-03-18 00:48:20]   ERROR   qrserver   fastespserver.contoso.com   15100   systemmsg   FastQT_Security: SSL Init (SSL client): Certificate in C:\esp\etc/FDSSM_client.pem is not valid

 

2 原因

=========

事象の原因は、SAM 関連処理で使用される証明書 (JAVA_server.key FDSSM_client.pem, FDSSM_private.pem など) の有効期限が切れたために発生しております。

本証明書は SAM のモジュール インストール時に既定で用意される証明書であり、協定世界時の 2017 3 17 13 (日本時間 2017 3 17 22) に有効期限が切れる動作となります。

事象を解消するためには、以下の [回避策] をご参考いただき、手動による証明書の更新が必要となります。

 

3 回避策

==========

SAM をインストールした際、既定では自己証明書を使用しておりますが、それ以外に公的機関から発行された証明書も使用可能です。

現時点でお問い合わせいただいたお客様におかれまして、全てが自己証明書をご利用いただいている状況を鑑みて、以下に自己証明書を利用した際の手順を記載いたします。

なお、公的な証明書から発行された証明書などを利用しているお客様の環境にて本事象が発生した場合は、別途マニュアル (1) を参照し、証明書の更新をご実施くださいますようお願いいたします。

 

(注1)

FAST_ESP_SecurityAccessModule.pdf の [APPENDIX A – CREATING YOUR OWN JAVA KEYSTORES AND SSL CERTIFICATES] 部分をご参照ください。

 

<事前説明>

以下は Windows FAST ESP の手順を例として記載いたします。

 

<手順>

  1. key ファイルの作成
  2. pem ファイルの配置
  3. QRserver と SAM 関連コンポーネントの再起動

 

  1. key ファイルの作成

———————

1-1) SAM サーバ上にログインし、管理者権限でコマンド プロンプトを立ち上げます。

1-2) 以下のコマンドを実行し、key ファイルを再作成します。

 

<コマンド>

cd %JAVA_HOME%\bin

keytool -genkey -keyalg “RSA” -storetype jks -dname “cn=SAM Key” -validity <days> -alias sam -keypass <key_password> -keystore <key_store_path> -storepass <key_password>

 

<パラメータ説明>

days           : 証明書の有効期限日数

key_password   : SAM の証明書作成時に使用するパスワード (SAM 構成時の既定値 : george)

key_store_path : key ファイルの出力パス。念のためローカル パスをご利用ください。

 

<コマンド例>

以下は days 3650 ( 10 )key_password george であり、key_store_path C:\test\JAVA_server.key の場合の例を記載いたします。

 

cd %JAVA_HOME%\bin

keytool -genkey -keyalg “RSA” -storetype jks -dname “cn=SAM Key” -validity 3650 -alias sam -keypass george -keystore C:\test\JAVA_server.key -storepass george

 

 

1-3) 出力先のディレクトリ ( : C:\test\) にアクセスし、JAVA_server.key をコピーし、JAVA_client.key にリネームします。

1-4) 手順 1-3) で作成した 2 つの key ファイル (JAVA_server.key JAVA_client.key) を全ての SAM サーバ上の以下のディレクトリに配置します (既存の JAVA_server.key 及び JAVA_client.key のバックアップを別途ご取得ください)

配置ディレクトリ : %FASTSEARCH%\lib\mars

配置ファイル     : JAVA_server.key, JAVA_client.key

 

1-5) SAM の Admin GUI にアクセスします。

1-6) 画面上部の [Advanced Configuration] をクリックし、表示された画面の下部の [Export KeyStore Form] をクリックします。

1-7) 表示された画面にて、以下の情報を入力します。

 

– Java KeyStore Path (Full Path on the Server)  : JAVA_server.key のパス

※ 上記 %FASTSEARCH%\lib\mars\JAVA_server.key のパスを指定します。念のためここでは絶対パスをご指定ください。 ( : C:\esp\lib\mars\JAVA_server.key)

– Java KeyStore Password                        : 上述 keytool key ファイル生成時に指定したパスワード ( : george)

– Alias of the RSA Key to export                : sam

– Password of the Key                           : 上述 keytool key ファイル生成時に指定したパスワード ( : george)

– Aliases of Additional Certificates to include : 空白のままで構いません。

– File name of the generated PEM file           : “pem ファイル出力先” + “java.pem” ( : C:\test\java.pem)

 

 

1-8) “Export” ボタン押下します。

※ ファイルが既に存在した場合、HTTP 500 エラーが発生することを弊社の環境にて確認しておりますので、テスト ディレクトリなどに出力ファイル名が重複しないようにご指定くださいますようお願いいたします。

 

1-9) “Export” 完了後、画面上部の [Advanced Configuration] をクリックし、表示された画面 (Advanced Configuration) の中央部分の [Miscellaneous Setting] セクションにて、[Key Store Password] ( : george) [Trust Store Password] ( : george) を入力します。

1-10) [Save] ボタンをクリックします。

※ 設定が反映されるまで数分ほどしばらくお待ちください。

 

1-11) 出力先のディレクトリ ( : C:\test\) にアクセスし、出力された pem ファイルを下記の通りにリネームします。

1-11-1) java.pem をコピーし、FDSSM_client.pem  にリネームします。

1-11-2) java.pem をコピーし、FDSSM_private.pem にリネームします。

 

 

  1. pem ファイルの配置

———————

2-1) 前述の手順 1-11-1) でリネームした FDSSM_client.pem を、ご利用の全ての Document Processing サーバーおよび QRserver 上の以下のディレクトリに配置します (既存の FDSSM_client.pem のバックアップを別途ご取得ください)

配置ディレクトリ : %FASTSEARCH%\etc

配置ファイル     : FDSSM_client.pem

 

2-2) 前述の手順 1-11-1) および 1-11-2) でリネームした FDSSM_private.pem FDSSM_client.pem を、ご利用の全ての SAM サーバー上の以下のディレクトリに配置します (既存の FDSSM_private.pem FDSSM_client.pem のバックアップを別途ご取得ください)

配置ディレクトリ : %FASTSEARCH%\securitymanager\main

配置ファイル     : FDSSM_private.pem, FDSSM_client.pem

 

 

  1. QRserver と SAM 関連コンポーネントの再起動

—————————-

3-1) QRserver 上にログインします。

3-2) 以下のコマンドを実行し、QRserver の再起動を実施します。

nctrl stop qrserver

nctrl start qrserver

 

3-3) SAM サーバにログインします。

3-4) 以下のコマンドを実行し、SAM 関連コンポーネントの再起動を実施します。

nctrl stop sec-ntfs

nctrl start sec-ntfs

 

 

Admin GUI よりもご実施いただけます。補足ではございますが、以下に Admin GUI より実施する方法を記載いたします。

 

補足 – Admin GUI より再起動する方法

————————————

1) FAST ESP の Admin GUI を立ち上げます。

2) [System Management] タブにアクセスします。

3) 画面中央部分の [Show extended information for all nodes] をクリックします。

4) 展開された画面において、Process Name qrserver, sec-ntfs であるコンポーネントを全て再起動します。

※ 再起動ボタンは、一番右側の矢印付きのものになります。

 

 

 

今回の投稿は以上となります。

————————————————————

本情報の内容(添付文書、リンク先などを含む)は、作成日時点でのものであり、予告なく変更される場合があります。

Microsoft Planner にて一般ユーザーによるプラン作成を制限する方法について (V2)

$
0
0

こんにちは、SharePoint サポートの森村です。
以前下記の記事にて Microsoft Planner (以下 Planner) のプラン作成を制限する方法をご案内しておりました。

タイトル : Microsoft Planner にて一般ユーザーによるプラン作成を制限する方法について
アドレス : https://blogs.technet.microsoft.com/sharepoint_support/2016/06/24/microsoft-planner-plan-create-restriction/

本日 (2017 3 27 日) 時点で、上記手順に必要なモジュールの提供が停止されており、再開の予定がない状態となります。こちらは、該当モジュールが Azure Active Directory PowerShell Module V1 Public Preview (ベータ) 版での提供であったことと、現在最新の Version 2 (V2) を開発、提供中であるためとなります。
このため、既に Azure Active Directory PowerShell Module V1 Public Preview 版をダウンロード済みの方は引き続き上記手順をご利用可能ですが、新規に上記手順をご利用いただくことはできません。

新規に設定を行いたい方のために、本記事では Azure Active Directory PowerShell Module V2 版を利用して Planner 上からプラン作成を制限する方法に関する、英語版の弊社技術情報ページの内容をご案内いたします。

タイトル : Azure Active Directory cmdlets for configuring group settings
アドレス : https://docs.microsoft.com/en-us/azure/active-directory/active-directory-accessmanagement-groups-settings-cmdlets

目次
1. Microsoft Planner にて全ユーザーによるプラン作成を制限する方法
2.
一部のユーザーのみにプラン作成を許可する方法
3.
再度全ユーザーにプラン作成を許可する方法 (設定を変更、削除する方法)
4.
インストール時、PowerShell 実行時にエラー メッセージが表示された場合
5.
関連情報

1. Microsoft Planner にて全ユーザーによるプラン作成を制限する方法

Planner 製品は Office 365 グループの機能を利用しております。
Planner
のページから [新しいプラン] をクリックすると、プランの名前の Office 365 グループが作成され、そのグループ用のプランとして Planner 上でプランの編集が可能となります。

しかし、テナントの管理方針によっては、自由に Office 365 グループの作成をさせたくない、ということも考えられます。
Planner
[新しいプラン] メニューでは、Outlook Web Access ページからの Office 365 グループ作成とは異なる機能を使用しているため、Exchange Online PowerShell にて、Set-OwaMailboxPolicy を使用し Office 365 グループの作成を禁止している場合でも新規にプラン (Office 365 グループ) が作成される動作となります。

このため、自由に Office 365 グループの作成をさせたくない場合は、下記手順にて Azure Active Directory PowerShell Module V2 を使用することで、全体管理者を含むすべてのユーザーに対し、Planner Outlook on the Web 上からのプランの作成 (Office 365 グループの作成) を禁止することが可能です。
(
ただし、全体管理者のユーザーの場合は、Office 365 管理センター上から Office 365 グループを作成することが可能です。)

事前準備手順

  1. 64 Bit OS が動作している Windows 10/8.1/7、あるいは Windows Server 2016/2012R2/2012/2008R2 を準備します。
  2. Windows 7 および Windows Server 2008 R2 の場合は、前提条件を満たすために、最新の Windows Update をすべて適用します。Windows Update 適用後に再起動を行います。(Windows 8.1 あるいは Windows Server 2012 以降の場合は 2. の手順は不要です。)
  3. Windows 7 および Windows Server 2008 R2 の場合は、下記弊社 TechNet ページを参照し、Microsoft Online Services サインイン アシスタントのインストールを行います。(Windows 8.1 あるいは Windows Server 2012 以降の場合は 3. の手順は不要です。)
    タイトル : Office 365 PowerShell への接続
    アドレス : https://technet.microsoft.com/ja-jp/library/dn975125.aspx
    
  4. Windows 7 および Windows Server 2008 R2 の場合は、下記リンクから .NET Framework 4.5 以降をインストールします。必要に応じて再起動を実施します。(Windows 8.1 あるいは Windows Server 2012 以降の場合は 4. の手順は不要です。)
    タイトル : .NET Framework のインストール
    アドレス : https://msdn.microsoft.com/ja-jp/library/5a4x27ek(v=vs.110).aspx
    
  5. Windows 7/8.1 および Windows Server 2008 R2/2012/2012 R2 の場合は、下記リンクから Windows Management Framework 5.0 をインストールします。必要に応じて再起動を実施します。(Windows 10 および Windows Server 2016 の場合は 5. の手順は不要です。)
    タイトル : Windows Management Framework 5.0
    アドレス : https://www.microsoft.com/en-us/download/details.aspx?id=50395
    
  6. PowerShell を管理者モードで起動し、下記コマンドを実行し、ネットワーク経由で最新版の Azure Active Directory PowerShell Module V2 をインストールします。
    Install-Module AzureADPreview
    

    ここで、「続行するには NuGet プロバイダーが必要です」、あるいは「NuGet provider is required to continue …」と表示されましたら、Y を入力し、先に進めてください。
    また、続けて「信頼されていないリポジトリ・・」と表示されましたら、Y を入力し、先に進めてください。

  7. PowerShell の実行ポリシーを変更していない場合は、続けて下記コマンドを実行します。(すでに変更済みの場合は 7. の手順は不要です。)
    Set-ExecutionPolicy RemoteSigned
    
  8. 管理者モードで起動した PowerShell ウィンドウを閉じます。

設定手順

  1. PowerShell を起動後、以下の 6 行のコマンドレットを実行します。2 行目の Connect-AzureAD を実行すると、認証ダイアログがポップアップされるので、該当テナントの全体管理者のアカウントとパスワードを入力します。
    Import-Module AzureADPreview;
    Connect-AzureAD;
    $template = Get-AzureADDirectorySettingTemplate -Id 62375ab9-6b52-47ed-826b-58e47e0e304b;
    $setting = $template.CreateDirectorySetting();
    $setting["EnableGroupCreation"] = $false;
    New-AzureADDirectorySetting -DirectorySetting $setting;
    

    なお、1 行目の Import-Module AzureADPreview にてエラーとなる場合は、Azure Active Directory PowerShell Module V2 が正しくインストールされていないことが原因として考えられます。
    上記「事前準備手順」を再度ご確認ください。

  2. 設定が反映されるまで、数分~1 時間程度待ちます。
  3. Planner にアクセスを行い、新規プラン作成を試みるとエラーメッセージが表示され、プランが作成できない動作に変化したことを確認します。

プランが作成できない場合のメッセージ
プランと Office 365 グループの作成が無効になっています
「プランと Office 365 グループの作成が無効になっています 組織のグローバル管理者が、新しいプランと Office 365 グループを作成する機能を無効にしています。」と表示されます。

2. 一部のユーザーのみにプラン作成を許可する方法

上記「1. Microsoft Planner にて全ユーザーによるプラン作成を制限する方法」では、すべてのユーザーによるプラン作成 (Office 365 グループ作成) を禁止しますが、
テナントの管理方針によっては、管理者等、一部のユーザーにはプラン作成を許可したい、ということも考えられます。

この場合は、上記 1. の方法に少し手順を追加することで、実現が可能です。

設定手順

  1. 上記 1. 事前準備手順を実施します。
  2. Office 365 管理センター上にて、セキュリティ グループを作成します。( : CanCreateGroups)
  3. プランを作成可能としたいユーザーをセキュリティ グループに追加します。
  4. PowerShell を起動後、以下のコマンドレットを実行します。<セキュリティ グループ名> の部分は適宜変更します。
    新規に設定を行う場合は、下記 9 行のコマンドレットを実行します。
    2
    行目の Connect-AzureAD を実行すると、認証ダイアログがポップアップされるので、該当テナントの全体管理者のアカウントとパスワードを入力します。
    Import-Module AzureADPreview;
    Connect-AzureAD;
    $groupname = "セキュリティ グループ名";
    $targetgroup = Get-AzureADGroup -SearchString $groupname | Where-Object { $_.DisplayName -eq $groupname};
    $template = Get-AzureADDirectorySettingTemplate -Id 62375ab9-6b52-47ed-826b-58e47e0e304b;
    $setting = $template.CreateDirectorySetting();
    $setting["EnableGroupCreation"] = $false;
    $setting["GroupCreationAllowedGroupId"] = $targetgroup.ObjectId;
    New-AzureADDirectorySetting -DirectorySetting $setting;
    

    既に「1. Microsoft Planner にて全ユーザーによるプラン作成を制限する方法」を実施済みの場合は、下記 8 行のコマンドレットを実行します。
    2
    行目の Connect-AzureAD を実行すると、認証ダイアログがポップアップされるので、該当テナントの全体管理者のアカウントとパスワードを入力します。

    Import-Module AzureADPreview;
    Connect-AzureAD;
    $groupname = "セキュリティ グループ名";
    $targetgroup = Get-AzureADGroup -SearchString $groupname | Where-Object { $_.DisplayName -eq $groupname};
    $setting = Get-AzureADDirectorySetting | Where-Object {$_.TemplateId -eq "62375ab9-6b52-47ed-826b-58e47e0e304b"};
    $setting["EnableGroupCreation"] = $false;
    $setting["GroupCreationAllowedGroupId"] = $targetgroup.ObjectId;
    Set-AzureADDirectorySetting -Id $setting.Id -DirectorySetting $setting;
    

    なお、1 行目の Import-Module AzureADPreview にてエラーとなる場合は、Azure Active Directory PowerShell Module V2 が正しくインストールされていないことが原因として考えられます。
    上記「事前準備手順」を再度ご確認ください。

  5. 設定が反映されるまで、数分~1 時間程度待ちます。
  6. セキュリティグループに含まれているユーザーにて Planner にアクセスを行い、新規プランの作成が可能であることを確認します。また、セキュリティ グループに含まれていないユーザーにて Planner にアクセスを行い、新規プラン作成を試みるとエラーメッセージが表示され、プランが作成できない動作であることを確認します。

3. 再度全ユーザーにプラン作成を許可する方法 (設定を変更、削除する方法)

プラン作成を禁止した後に、再度全ユーザーに対しプラン作成を許可したい場合は、下記手順にて設定値の変更を行うことで、テナントの設定が変更され、再度プラン作成が可能となります。

設定手順

  1. 上記 1. 事前準備手順を実施します。
  2. PowerShell を起動後、以下の 6 行のコマンドレットを実行します。
    2
    行目の Connect-AzureAD を実行すると、認証ダイアログがポップアップされるので、該当テナントの全体管理者のアカウントとパスワードを入力します。
    Import-Module AzureADPreview;
    Connect-AzureAD;
    $setting = Get-AzureADDirectorySetting | Where-Object {$_.TemplateId -eq "62375ab9-6b52-47ed-826b-58e47e0e304b"};
    $setting["EnableGroupCreation"] = $true;
    $setting["GroupCreationAllowedGroupId"] = "";
    Set-AzureADDirectorySetting -Id $setting.Id -DirectorySetting $setting;
    
  3. 設定が反映されるまで、数分~1 時間程度待ちます。
  4. 一般ユーザーにて Planner にアクセスを行い、新規プラン作成が可能となったことを確認します。
  5. 以降は任意の手順となりますが、“EnableGroupCreation”“GroupCreationAllowedGroupId” 以外の設定を変更していない場合は、追加で下記 4 行のコマンドレットを実行することで、設定を削除することが可能です。必ず先に 2. の手順にて “EnableGroupCreation” の設定値を変更後に削除をお願いいたします。
    Import-Module AzureADPreview;
    Connect-AzureAD;
    $setting = Get-AzureADDirectorySetting | Where-Object {$_.TemplateId -eq "62375ab9-6b52-47ed-826b-58e47e0e304b"};
    Remove-AzureADDirectorySetting -Id $setting.Id;
    

4. インストール時、PowerShell 実行時にエラーメッセージが表示された場合

PowerShell モジュールのインストール時や、PowerShell の実行時にエラー メッセージが表示される場合があります。
主なパターンについてトラブルシュート方法を記載します。

a. 32 ビット PC Azure Active Directory PowerShell Module のインストールを試みた場合
b.
前提条件のソフトウェアのインストールを行っていない場合
c.
以前のバージョンの Azure Active Directory PowerShell Moduleを使用している場合
d.
既にテナント上にプラン作成許可、制限の設定が行われている場合

a. 32 ビット PC Azure Active Directory PowerShell Module のインストールを試みた場合

Azure Active Directory PowerShell Module は、64 ビット版のみをサポートしております。(参考ページ)
このため、32 ビット版の Windows OS に対してインストールを試みると、下記の様なエラーが表示されます。
事前準備手順にも記載いたしましたように、64 ビット版の Windows OS 上で再度実施してください。

32 ビット版 Windows OS 上に表示されるメッセージ例
cannotinstallto32bit

-------- エラー内容 ここから --------
このインストールパッケージはこの種類のプロセッサでサポートされていません。プロダクトベンダーに問い合わせてください。
-------- エラー内容 ここまで --------

b. 前提条件のソフトウェアのインストールを行っていない場合

事前準備手順の一部を実施していない場合、事前準備手順 5 の Windows Management Framework 5.0 のインストールに失敗する、6 Install-Module AzureADPreview の実行等に失敗する場合があります。
恐れ入りますが今一度事前準備手順を最初から見直していただき、手順すべての実施をお願いします。

c. 以前のバージョンの Azure Active Directory PowerShell Moduleを使用している場合

本記事内にてプラン作成を制限する際に使用するコマンド群は、最新版の Azure Active Directory PowerShell Module V2 にのみ含まれております。
これ以前のバージョンの Azure Active Directory PowerShell Module V1 などを使用していた場合は、下記の様なエラー メッセージが表示されます。
事前準備手順を再度確認し、最新版の Azure Active Directory PowerShell Module V2 のインストールを行ってください。

以前のバージョンの Azure Active Directory PowerShell Module を使用している場合のエラー メッセージ例
Get-AzureADDirectorySetting : 用語 'Get-AzureADDirectorySetting' は、コマンドレット、関数、スクリプト ファイル、または操作可能なプログラムの名前として認識されません。名前が正しく記述されていることを確認し、パスが含まれている場合はそのパスが正しいことを確認してから、再試行してください。

-------- エラー内容 ここから --------
Get-AzureADDirectorySetting : 用語 'Get-AzureADDirectorySetting' は、コマンドレット、関数、スクリプト ファイル、または操作可能なプログラムの名前として認識されません。名前が正しく記述されていることを確認し、パスが含まれている場合はそのパスが正しいことを確認してから、再試行してください。
発生場所 行:1 文字:1
+ Get-AzureADDirectorySetting
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : ObjectNotFound: (Get-AzureADDirectorySetting:String) [], CommandNotFoundException
    + FullyQualifiedErrorId : CommandNotFoundException
-------- エラー内容 ここまで --------

d. 既にテナント上にプラン作成許可、制限の設定が行われている場合

既にプラン作成を制限する設定をテナント上に行っている状態で、「1. Microsoft Planner にて全ユーザーによるプラン作成を制限する方法」を実施した場合、New-AzureADDirectorySetting コマンドで追加される設定内容がすでに存在するため、下記の様なエラーが表示されて処理が失敗します。
この状況で設定変更を行うためには、「2. 一部のユーザーのみにプラン作成を許可する方法」内の、『既に「1. Microsoft Planner にて全ユーザーによるプラン作成を制限する方法」を実施済みの場合は、下記 8 行のコマンドレットを実行します。』の方法にて、設定内容を変更します。

既にテナント上にプラン作成許可、制限の設定が行われている場合のエラー メッセージ例
New-AzureADDirectorySetting : Error occurred while executing NewDirectorySetting

-------- エラー内容 ここから --------
New-AzureADDirectorySetting : Error occurred while executing NewDirectorySetting
Code: Request_BadRequest
Message: A conflicting object with one or more of the specified property values is present in the directory.
InnerError:
  RequestId: ea60b111-c8e8-4c14-942e-6c3b9b5bdfbb
  DateTimeStamp: Fri, 24 Mar 2017 04:14:51 GMT
HttpStatusCode: BadRequest
HttpStatusDescription: Bad Request
HttpResponseStatus: Completed
発生場所 行:1 文字:1
+ New-AzureADDirectorySetting -DirectorySetting $setting;
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [New-AzureADDirectorySetting], ApiException
    + FullyQualifiedErrorId : Microsoft.Open.MSGraphBeta.Client.ApiException,Microsoft.Open.MSGraphBeta.PowerShell.NewDirectorySetting
-------- エラー内容 ここまで --------

5. 関連情報

タイトル : Azure Active Directory cmdlets for configuring group settings
アドレス : https://docs.microsoft.com/en-us/azure/active-directory/active-directory-accessmanagement-groups-settings-cmdlets

タイトル : PowerShell ギャラリー
アドレス : https://msdn.microsoft.com/powershell/gallery/readme

今回の投稿は以上です。


本情報の内容(添付文書、リンク先などを含む)は、作成日時点でのものであり、予告なく変更される場合があります。


Search Query Tool のご紹介

$
0
0

こんにちは。SharePoint サポートの清です。

今回は、検索結果の管理プロパティの値などを確認する場合に有用なツール(Search Query Tool)を紹介したいと思います。

 

SharePoint 2013 以降のバージョンでは、検索 REST サービスを使用して、検索結果を取得することができます。
Search Query Tool は、この仕組みを利用したツールとなり、SharePoint 2013, SharePoint 2016, SharePoint Online で使用できます。

codeplex のツールのサポートは提供しておりませんが、Search Query Tool はインストール不要で簡単にプロパティ値を確認することや、対象のアイテムがクロールされているかの判断にもご利用いただける便利なツールですので、必要に応じてご活用いただければ幸いです。

 

<目次>

1. ダウンロード方法

2. Search Query Tool の使用方法

 

1. ダウンロード方法
================

ツールのダウンロード先は以下です。

タイトル : SharePoint 2013 Search Query Tool
アドレス : http://sp2013searchtool.codeplex.com/

1

1) 上記リンクより、紫色の [download] ボタンをクリックし、SharePoint 2013 Search Query Tool をダウンロードします。
2) SearchQueryToolv2.5.zip をダウンロードします。
※ 上記は、現時点で公開されているファイル名となり、タイミングによりバージョンが異なる場合があります。その際は、読み替えてダウンロードしてください。
3) デスクトップなどに解凍します。

 

2. Search Query Tool の使用方法
================================

SearchQueryTool.exe を起動し、プロパティの返り値などを確認します。
今回は、例として SharePoint 2016 で、テストファイルのプロパティ値を確認してみたいと思います。

 

ステップ 1: 接続設定

Connection 枠に、検索を行う SharePoint サイトの URL を指定し、認証情報を設定します。


オンプレミス (SharePoint 2013, SharePoint 2016) 環境の場合

2


SharePoint Online
環境の場合

3

 

ステップ 2: クエリの指定

Query 枠の Query Text: に、確認したいアイテムを検索結果に表示するためのクエリを指定します。

* 検索ボックスに検索キーワード(「テスト」など)を入力し、対象のアイテムがヒットする場合は、その検索キーワードをツールに入力していただいても構いません。
* その他、パスベースで指定する場合には、以下のように入力します。(オンプレミス環境の場合、クロール ログに記載されている URL となります。)
リスト アイテムの場合 Path:”http://servername/sites/sitename/Lists/List1/DispForm.aspx?ID=1
ファイルの場合 Path:”http://servername/DocLib/test.txt


クエリが指定できたら、[Run] ボタンをクリックします。

4


Primary Results
タブをクリックし、検索結果の詳細を確認します。

5

  

ステップ 3: すべてのプロパティの表示

表示されたアイテムの View をクリックして、展開します。

6


一番下の項目の View all properties… のリンクをクリックすることで、表形式でプロパティを表示することが可能です。

7


プロパティの値を確認します。

8

9

 

ツールを終了する場合は、ウィンドウ右上の [X] ボタンをクリックします。
ツールを削除する場合は、解凍したフォルダごと削除します。

 

 

いかがでしたでしょうか。

ご利用環境に何らかの問題が発生した時の確認にお役立ていただければ幸いです。

検索機能でお困りなことがありましたら、是非私たちサポート サービスのご利用もご検討ください!:)

今回の投稿は以上となります。

 

————————————————————

本情報の内容(添付文書、リンク先などを含む)は、作成日時点でのものであり、予告なく変更される場合があります。

 

日付選択 (カレンダー) コントロールの表示にインターネット領域のセキュリティ設定が使用される

$
0
0

こんにちは! SharePoint サポートの大竹です。
今回は、イントラネット領域や、信頼済みサイトに登録しているページの日付選択 (カレンダー) コントロールの表示に、インターネット領域のセキュリティ設定が使用される事象について解説いたします。
その結果、インターネット領域のセキュリティ設定が高いと、日付選択用のカレンダーが表示されない事象が発生します。
本事象の原因と、回避方法についてご案内します。

 

===========================
日付選択コントロールとは?
===========================
日付選択コントロールとは、以下のような、特定の日付を選択したり、入力したりするフォームのことです。
cap3

 

日付選択用のカレンダーが表示されない事象について
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
SharePoint サイトがイントラネット ゾーンや信頼済みサイトに登録されている場合でも、インターネット ゾーンのセキュリティ設定を強固に設定されていると、動的に描画された日付選択コントロールが正しく動作しません。
特に、リスト アイテムの新規作成画面 NewForm.aspx や、編集画面 EditForm.aspx において日付列の編集をする際、この事象が発生することを確認しております。
(キーボードによる、テキストボックスへの入力は可能ですが、カレンダーが表示されないため、日付を選択することができません。)

本動作は SharePoint サイトに限定したものではありませんが、HTML コンテンツに動的に要素を挿入するページにアクセスした場合、Internet Explorer の動作制限により上記事象が発生します。
Internet Explorer は通常、ページを表示した際に作成されたオブジェクトすべてを同様のセキュリティ ゾーンとして処理を行います。
しかしながら、ページ表示後、動的に挿入された要素に対しては、セキュリティの観点から “独立したオブジェクト” として作成されます。
この独立したマークアップ オブジェクトは、URL などのロケーション情報を持たないため、”about:blank” の URL として扱われます。
“about:blank” は既定で “インターネット” ゾーンとして動作するため、挿入された要素はすべて “インターネット” ゾーンのセキュリティ設定の影響を受けます。

 

====================
回避方法について
====================
以下のいずれかの方法で回避できます。

1. 信頼済みサイトに “about:blank” を追加する
————————————————————————-
信頼済みサイトや、イントラネット ゾーンに “about:blank” URL を登録していただくことで事象が回避します。

cap1

 

2. インターネット ゾーンのセキュリティ設定において “アクティブ スクリプト” を有効にする
—————————————————————————————————————————-
インターネット ゾーンのセキュリティ設定において “アクティブ スクリプト” を有効にすることでも回避することが可能です。

cap2

 

==============
ご留意事項
==============
以下の理由によりセキュリティの影響が低いのは 「2. インターネット ゾーンのセキュリティ設定において “アクティブ スクリプト” を有効にする」となります。
お客様のご運用状況に合わせてご選択ください。

– インターネット ゾーンのセキュリティ項目の “アクティブ スクリプト” の設定を “有効にする” にした場合でも、インターネット ゾーンの Web コンテンツの処理は、インターネット ゾーンのセキュリティ範囲を超えて実行されることは無い。

– “about:blank” を信頼済みサイトゾーンに追加した場合、インターネット ゾーンの Web コンテンツのスクリプト処理から動的に生成される HTML やスクリプト処理が信頼済みサイトゾーンの権限で実行されるリスクがある。

なお、外部インターネットには接続不可の環境で Internet Explorer をご利用いただく場合は、”about:blank” を信頼済みサイト ゾーンに追加した場合のリスクは低いと考えられますので、ご利用のシステム環境に応じてご対応方針をご検討ください。

Yammer グループと Office 365 グループの統合について (V2)

$
0
0

こんにちは、SharePoint サポート チームの関 友香です。

 

先日投稿いたしました ブログ記事 にて、Yammer グループと紐づく Office 365 グループの作成を制限する方法としてテナント上で Office 365 グループの作成を制限する方法をご案内しております。本日 (2017/4/6)  時点で、手順を実施するために必要なモジュールの適用が停止されており、再開の予定がない状態であることを確認しております。該当モジュールが Azure Active Directory PowerShell Module V1 Public Preview (ベータ) 版での提供であったことと、現在最新の Version 2 (V2) を開発、提供中であるためとなります。

既に Azure Active Directory PowerShell Module V1 Public Preview 版をダウンロード済みの方は引き続き同様の手順をご利用可能ですが、これから新規で設定を行う方 (ダウンロード未実施の方) は Azure Active Directory PowerShell Module V2 版を使用する必要があります。

これから設定を行いたい方のために、本記事では Azure Active Directory PowerShell Module V2 版を利用して Office 365 グループを制限する方法をご紹介いたします。

 

Yammer グループと紐づく Office 365 グループ制限する方法

今回の投稿でも、下記それぞれの方法について手順をご案内させていただきます。なお、以下のいずれの方法を設定した場合においても、全体管理者とユーザー管理の管理者は Yammer グループに紐づく Office 365 グループを作成することが可能です。

(A) テナント単位で Office 365 グループの作成を無効とする方法

Yammer で作成したグループは Office 365 側には連携されず、Yammer グループに紐づく Office 365 グループは作成されません。

Office 365 グループ作成の制限は Yammer 上でのグループ作成には影響を及ぼしませんので、すべてのユーザーは引き続き Yammer 上でグループを作成することが可能です。

(B) 特定のセキュリティ グループのメンバーのみ Office 365 グループの作成を制限する方法

・ユーザーが Office 365 グループの作成を許可されたセキュリティ グループのメンバーである場合には、ユーザーが Yammer 上で作成したグループと連携した Office 365 グループが Office 365 上でも作成されます。

・ユーザーが Office 365 グループの作成を許可されたセキュリティ グループのメンバーでない場合には、ユーザーは Yammer 上で引き続きグループを作成することは可能ですが、Yammer グループと連携した Office 365 グループは作成されません。

Office 365 グループ作成の制限は Yammer 上でのグループ作成には影響を及ぼしませんので、すべてのユーザーは引き続き Yammer 上でグループを作成することが可能です。

 

設定手順について

以下に記載いたします設定の内容は、公開情報 Azure Active Directory cmdlets for configuring group settings (英語版) をもとに作成しております。

なお、Office 365 グループは Yammer 以外の様々な Office 365 上のサービスでも利用されておりますので、本設定を適用される際には各サービスの管理者様と設定内容について十分にご検討ください。

 

事前準備

1. 64 Bit OS が動作している Windows 10/8.1/7、あるいは Windows Server 2016/2012R2/2012/2008R2 を準備します。

2. Windows 7 および Windows Server 2008 R2 の場合は、前提条件を満たすために、最新の Windows Update をすべて適用します。Windows Update 適用後に再起動を行います。(Windows 8.1 あるいは Windows Server 2012 以降の場合は 2. の手順は不要です。)

3. Windows 7 および Windows Server 2008 R2 の場合は、下記弊社 TechNet ページを参照し、Microsoft Online Services サインイン アシスタントのインストールを行います。(Windows 8.1 あるいは Windows Server 2012 以降の場合は 3. の手順は不要です。)

・ Office 365 PowerShell への接続

https://technet.microsoft.com/ja-jp/library/dn975125.aspx

4. Windows 7 および Windows Server 2008 R2 の場合は、下記リンクから .NET Framework 4.5 以降をインストールします。必要に応じて再起動を実施します。(Windows 8.1 あるいは Windows Server 2012 以降の場合は 4. の手順は不要です。)

・  .NET Framework のインストール

https://msdn.microsoft.com/ja-jp/library/5a4x27ek(v=vs.110).aspx

5. Windows 7/8.1 および Windows Server 2008 R2/2012/2012 R2 の場合は、下記リンクから Windows Management Framework 5.0 をインストールします。必要に応じて再起動を実施します。(Windows 10 および Windows Server 2016 の場合は 5. の手順は不要です。)

・ Windows Management Framework 5.0

https://www.microsoft.com/en-us/download/details.aspx?id=50395

6. PowerShell を管理者モードで起動し、下記コマンドを実行し、ネットワーク経由で最新版の Azure Active Directory PowerShell Module V2 をインストールします。

——–
Install-Module AzureADPreview
——–

※ ここで、「続行するには NuGet プロバイダーが必要です…」、あるいは「NuGet provider is required to continue …」と表示されましたら、Y を入力し、先に進めてください。

また、続けて「信頼されていないリポジトリ・・」と表示されましたら、Y を入力し、先に進めてください。

7. PowerShell の実行ポリシーを変更していない場合は、続けて下記コマンドを実行します。(すでに変更済みの場合は 7. の手順は不要です。)

——–
Set-ExecutionPolicy RemoteSigned
——–

8. 管理者モードで起動した PowerShell ウィンドウを閉じます。

 

設定手順

(A) テナント単位で Office 365 グループの作成を無効とする方法

1. PowerShell を起動後、以下のコマンドレットを実行します。

——–
Import-Module AzureADPreview;
Connect-AzureAD;
$template = Get-AzureADDirectorySettingTemplate -Id 62375ab9-6b52-47ed-826b-58e47e0e304b;
$setting = $template.CreateDirectorySetting();
$setting[“EnableGroupCreation”] = $false;
New-AzureADDirectorySetting -DirectorySetting $setting;
——–

※ 1 行目の Import-Module AzureADPreview にてエラーとなる場合は、Azure Active Directory PowerShell Module V2 が正しくインストールされていないことが原因として考えられます。
上記「事前準備手順」を再度ご確認ください。

9 行目の New-AzureADDirectorySetting にてエラーとなる場合は、過去に設定オブジェクトを作成している可能性がございます。その場合には、後述いたします手順 「(C) 設定内容を変更する方法」 の “テナントで Office 365 グループの作成を無効としたい場合” をご確認ください。

2. 設定内容を確認したい場合には、下記のコマンドを実施してください。EnableGroupCreation が “False” に設定されていることを確認します。(下図参照)

——–
$setting.Values
——–

b

3. 設定が反映されるまで、数分~1 時間程度待ちます。

 

補足

・ 2017 年 4  5 日時点の動作では、上記の設定にて全体管理者とユーザー管理の管理者は Yammer グループに紐づく Office 365 グループを作成することが可能です。

 2017  4  5 日時点の動作では、全体管理者は、Office 365 管理センターの [グループメニューから Office 365 グループを作成することが可能ですが、Outlook on the Web 等の Office 365 グループの UI 上からは Office 365 グループを作成することはできません。

 2017  4  5 日時点の動作では、ユーザー管理の管理者は、Office 365 管理センターの [グループメニューからセキュリティ グループのみ作成が可能ですが、Outlook on the Web 等の Office 365 グループの UI 上からは Office 365 グループを作成することはできません。

 

 

(B) セキュリティ グループ単位で Office 365 グループの作成を制限する

1. 設定に使用するセキュリティ グループを用意します。 (. AllowedtoCreateGroups)

2. PowerShell を起動後、以下のコマンドレットを実行します。<セキュリティ グループ名> の部分は適宜変更します。新規に設定を行う場合は、下記 9 行のコマンドレットを実行します。
2
行目の Connect-AzureAD を実行すると、認証ダイアログがポップアップされるので、該当テナントの全体管理者のアカウントとパスワードを入力します。

——–
Import-Module AzureADPreview;
Connect-AzureAD;
$groupname = “セキュリティ グループ名“;
$targetgroup = Get-AzureADGroup -SearchString $groupname | Where-Object { $_.DisplayName -eq $groupname};
$template = Get-AzureADDirectorySettingTemplate -Id 62375ab9-6b52-47ed-826b-58e47e0e304b;
$setting = $template.CreateDirectorySetting();
$setting[“EnableGroupCreation”] = $false;
$setting[“GroupCreationAllowedGroupId”] = $targetgroup.ObjectId;
New-AzureADDirectorySetting -DirectorySetting $setting;
——–

9 行目の New-AzureADDirectorySetting にてエラーとなる場合は、過去に設定オブジェクトを作成している可能性がございます。その場合には、後述いたします手順 「(C) 設定内容を変更する方法」 の  “セキュリティ グループを変更したい場合” をご確認ください。

3. 設定内容を確認したい場合には、下記のコマンドを実施してください。EnableGroupCreation が “False” および GroupCreationAllowedGroupId に対象グループのオブジェクト ID が追加されていることを確認します。(下図参照)

——–
$setting.Values
——–

a

4. 設定が反映されるまで、数分~1 時間程度待ちます。

 

補足

 2017  4  5 日時点の動作では、上記の設定にて許可したセキュリティ グループのメンバーおよび全体管理者とユーザー管理の管理者は Yammer グループに紐づく Office 365 グループを作成することが可能です。

 2017  4  5 日時点の動作では、上記の設定にて許可したセキュリティ グループのメンバーに含まれていない全体管理者は、Office 365 管理センターの [グループメニューから Office 365 グループを作成することが可能ですが、Outlook on the Web 等の Office 365 グループの UI 上からは Office 365 グループを作成することはできません。

 2017  4  5 日時点の動作では、上記の設定にて許可したセキュリティ グループのメンバーに含まれていないユーザー管理の管理者は、Office 365 管理センターの [グループメニューからセキュリティ グループのみ作成が可能ですが、Outlook on the Web 等の Office 365 グループの UI 上からは Office 365 グループを作成することはできません。

・ 指定できるセキュリティ グループは 1 つのみですが、Office 365 管理センターで、指定したグループに複数のセキュリティ グループを入れ子にすることが可能です。

・ 一度設定したセキュリティ グループを変更する場合は、以下の「(C) 設定内容を変更する方法」 をご実施ください。

 

(C) 設定内容を変更する方法

1. PowerShell を起動後、以下の 6 行のコマンドレットを実行します。
2
行目の Connect-AzureAD を実行すると、認証ダイアログがポップアップされるので、該当テナントの全体管理者のアカウントとパスワードを入力します。
——–
Import-Module AzureADPreview;
Connect-AzureAD;
$setting = Get-AzureADDirectorySetting | Where-Object {$_.TemplateId -eq “62375ab9-6b52-47ed-826b-58e47e0e304b”};
——–

2. 変更内容に応じて、下記のコマンドを実施します。

テナントで Office 365 グループの作成を無効としたい場合 :

——–

$setting[“EnableGroupCreation”] = $false;
$setting[“GroupCreationAllowedGroupId”] = “”;
Set-AzureADDirectorySetting -Id $setting.Id -DirectorySetting $setting;
——–

 テナントで Office 365 グループの作成を有効としたい場合 :

——–

$setting[“EnableGroupCreation”] = $true;
$setting[“GroupCreationAllowedGroupId”] = “”;
Set-AzureADDirectorySetting -Id $setting.Id -DirectorySetting $setting;
——–

セキュリティ グループを変更したい場合 :

——–

$groupname = “セキュリティ グループ名” ;
$targetgroup = Get-AzureADGroup -SearchString $groupname | Where-Object { $_.DisplayName -eq $groupname};

$setting[“EnableGroupCreation”] = $false;
$setting[“GroupCreationAllowedGroupId”] = $targetgroup.ObjectId

Set-AzureADDirectorySetting -Id $setting.Id -DirectorySetting $setting;

——–

3 行目では EnableGroupCreation を “False” に変更するために記載していますが、もともと設定値を False に設定している場合には実行いただく必要はございません。

下記手順 3 にて EnableGroupCreation が “False” GroupCreationAllowedGroupId に対象グループのオブジェクト ID が追加されていることを確認してください。

 

3. 下記のコマンドを実施して設定内容を確認します。

——–
$setting.Values
——–

4. 設定が反映されるまで、数分~1 時間程度待ちます。

 

[参考情報]

タイトル : Azure Active Directory cmdlets for configuring group settings

アドレス : https://docs.microsoft.com/en-us/azure/active-directory/active-directory-accessmanagement-groups-settings-cmdlets

 

タイトル : Yammer グループと Office 365 グループの統合について

アドレス : https://blogs.technet.microsoft.com/sharepoint_support/2017/03/10/manage-yammer-suite-connected-office-365-group-creation

 

今回の投稿は以上になります。

 

本情報の内容は、作成日時点でのものであり、予告なく変更される場合があります。

SharePoint Server 2016 に Office 2016 をインストールした際の事象について

$
0
0

こんにちは。SharePoint サポートの 門 (かど) です。
今回は SharePoint Server 2016 に、Office 2016 をインストールした際の事象についてご報告します。

 

[概要]
SharePoint Server 2016 がインストールされている Windows Server に Office 2016 をインストールすることにより、SharePoint Server 2016 が正常に動作しなくなることが確認されました。

 

[詳細]
SharePoint Server 2016 に Office 2016 をインストールした場合、w3wp.exe が起動する際にロードする内部モジュールが不正な状況となり、新規アプリケーション プール w3wp.exe が起動できなくなることを確認しております。
一例として、以下のような動作となることを確認しております。

・Office 2016 のインストール直後から、SharePoint 2016 管理シェルが正常に起動しなくなります。

20170411kakado01

 

・Office 2016 のインストール直後には SharePoint Server 2016 サイトへのアクセスは可能ですが、SharePoint Server 2016 で利用しているアプリケーション プールがリサイクルされたタイミングで、同サイトへのアクセスが行えなくなります。
また、同サイトへのアクセスによりアプリケーション プールは「停止」状態となりますが、マニュアル操作で「開始」させた上で再度サイトへのアクセスを行うと、再び「停止」状態となります。

20170411kakado002

 

・Windows Server の再起動を行うと、SharePoint Server 2016 関連のサービスが起動しなくなります。

20170411kakado003

 

[発生条件]
「Windows インストーラー形式 (MSI)」で提供されている「ボリューム ライセンス版 (VL)」の Office 2016 を利用してインストールを行った場合にのみ、本事象が発生します。

「クイック実行形式 (C2R)」で提供されている Office 2016 を「Windows インストーラー形式 (MSI)」である SharePoint Server 2016 へインストールすると、以下のようなエラーとなり Office 2016 のインストールは行われないため本事象は発生いたしません。

20170411kakado004

 

「クイック実行形式 (C2R)」と「Windows インストーラー形式 (MSI)」の詳細につきましては、以下の参考情報をご確認ください。

 – 参考情報

タイトル : 同一コンピューターでクイック実行および Window インストーラーを使ってインストールされた Office はサポートされない
アドレス : https://support.office.com/ja-jp/article/30775ef4-fa77-4f47-98fb-c5826a6926cd/

タイトル : クイック実行形式 (C2R) と Windows インストーラー形式 (MSI) を見分ける方法
アドレス : https://blogs.technet.microsoft.com/officesupportjp/2016/09/08/howto_c2r_or_msi/

 

[回避策]
本事象については現在詳細を確認中で、有効な回避策の有無についても合わせて確認を行っております。
現時点におきましては、「SharePoint Server 2016 がインストールされている Windows Server には、Office 2016 のインストールを行わない」ようお願いいたします。

 

今回の投稿は以上となります。

本情報の内容 (添付文書、リンク先などを含む) は、作成日時点でのものとなります。

また、本事象に関する情報が確認されましたら、本ブログも随時更新させていただく予定です。

SharePoint Online の添付ファイルのダウンロードの動作について

$
0
0

こんにちは。SharePoint サポートの井上です。

 

今回の投稿では、SharePoint Online でリスト アイテムの添付ファイルを、ブラウザーのメニューから保存する場合の動作についてご説明いたします。

 

概要

リスト アイテムに添付された Office ファイルのリンクを右クリックし、ブラウザーのコンテキストメニューの [対象をファイルに保存] (ブラウザーによって、メニューの表記は異なります) をクリックすると、Office ファイル (.docx、.xslx など) ではなく WopiFrame.htmがダンロードされる動作が発生する場合があります。

fig1

 

本動作は、サイト コレクションの機能が既定の状態の場合に、新しい GUI のカスタム リスト以外で発生し得る、製品の動作制限となります。

本現象が発生する場合は、添付ファイルのリンクをクリックすると Office Online (ブラウザー上で動作する Web 版の Office アプリケーション) が起動しますので、Office Online のメニューからファイルをダウンロードしてください。

fig2

 

なお、新しい GUI のカスタム リストでは、本動作への対応が実施されており、ブラウザーのコンテキストメニューの [対象をファイルに保存] からファイルをダウンロードすることが可能です。

* 新 GUI は従来とは異なる新しい技術が使用されており、旧 GUI では対応できなかった動作も随時対応が進んでおります。

fig4

 

動作の詳細について

本動作は、サイト コレクション機能の “既定でクライアント アプリケーションでドキュメントを開く” が影響します。

既定で本機能は無効であり、サイト コレクションの管理者以上の権限を所有しているユーザーのみ、サイトの設定ページから設定を変更できます。

fig3

 

本機能が無効の場合、ドキュメント ライブラリのファイルや、リスト アイテムの添付ファイルをクリックした場合、Office ファイルの場合は Office Online でファイルが開く動作になります。

このため、リスト アイテムの添付ファイルについて、HTML にマークアップされるリンク先 URL は、Office Online でファイルを開くためのページの URL (<サイト コレクションの URL>/_layouts/WopiFrame.aspx?<各種パラメータ>) になり、Office ファイルの実体へのリンクとはなりません。

この状態で、ブラウザーのコンテキストメニューの [対象をファイルに保存] を実行すると、Office Online でファイルを開くためのページのダウンロードを試みるため、Office ファイルではなく、WopiFrame.htm がダウンロードされる動作となります。

テキストファイル (.txt) など、Office ファイル以外は Office Online で開くことができないため、Office Online でファイルを開くためのページの URL が生成されず、本現象は発生しません。

 

なお、ドキュメント ライブラリにおいては、旧 GUI においても本現象は発生しません。

ドキュメント ライブラリは、ドキュメントの管理に最適化されたライブラリとなるため、旧 GUI においてもファイルのリンクを右クリックすると、ブラウザーのコンテキストメニューではなく、ドキュメントの操作に特化した専用のメニューが表示されます。

ブラウザーのコンテキストメニューの [対象をファイルに保存] が実行できないため、本現象の発生には至らない動作となります。

fig7

 

本動作を変更するためには、サイト コレクション機能の “既定でクライアント アプリケーションでドキュメントを開く” をアクティブ化することで、リスト アイテムの添付ファイルの URL が、Office Online でファイルを開くためのページではなく、Office ファイルの実体へのリンクに変更されます。この状態で、ブラウザーのコンテキストメニューからファイルを保存すると、Office ファイルがダウンロードされる動作に変更されます。

しかしながら、本機能をアクティブ化することで、ドキュメント ライブラリなどで Office ファイルをクリックした場合に、Office Online ではなく、端末にインストールされた Office アプリケーションでファイルを開くことを試みるように動作が変更されます。本動作には、Internet Explorer のアドオンが影響するなど、ブラウザーによって動作が異なりますので、設定変更を実施される場合は、ご利用いただいている環境で事前に十分に動作をご確認されることをご検討ください。

 

参考情報

以下の情報はオンプレミスの SharePoint を対象にしていますが、SharePoint Online でも同様にご参考にいただけます。

タイトル : ブラウザー対応ドキュメントの既定のオープン動作を設定する (SharePoint 2013 と組み合わせて使用するOffice Web Apps)
アドレスhttp://technet.microsoft.com/ja-jp/library/ee837425(v=office.15).aspx

 

まとめ

以下の条件を満たす場合に、リスト アイテムの添付ファイルをブラウザーのメニューからダウンロードすることはできません。この場合は、Office Online のダウンロード機能をご利用ください。

・サイト コレクション機能の既定でクライアント アプリケーションでドキュメントを開くが無効

・添付ファイルが、Office ファイル (.docx.xslx など)

 

また、サイト コレクション機能の既定でクライアント アプリケーションでドキュメントを開くをアクティブ化することで、添付ファイルをダウンロードする動作を変更することができます。

ただし、ドキュメント ライブラリ、及び各種リストの添付ファイルをクリックした場合の動作が変更されるので、設定変更を実施される場合は予めご留意ください。

 

今回の投稿は以上です。

本情報の内容は、作成日時点でのものであり、予告なく変更される場合があります。

Viewing all 182 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>