kazuakix の日記

Windows Phone とか好きです

PowerShell で Office 365 に接続する (2018.02 版)

 フォーラムで見かけたのですが、少し前から PowerShell で Office 365 に接続するためのツールである Microsoft PowerShell の Microsoft Azure Active Directory モジュールのインストール方法が変わっています。
 
 Office 365 PowerShell への接続の記事中では、ツールをインストールするために「Azure Active Directory Connection の Web ページを開きます」と書かれているのですが、実際に開くと、「Microsoft Connect は無くなったので、Microsoft Collaborate を見てね」というページが表示れます。

f:id:kazuakix:20180205204912p:plain

そして Microsoft Collaborate のページを探しても、それらしいツールを見つけることはできません。
 
 今 (2018 年 2 月現在) 、PowerShell で Office 365 に接続する手順は以下のようになっています。

1. Microsoft Online Services サインイン アシスタントの 64 ビット バージョンをインストール

IT プロフェッショナル 用 Microsoft Online Services サインイン アシスタント RTW からダウンロードしてインストールします。
 

2 . PowerShell から Microsoft PowerShell の Microsoft Azure Active Directory モジュールをインストール

 PowerShell を管理者として実行し、 Install-Module を使ってモジュールをインストールします。 (途中の選択肢はどちらも Y を選んでおきます)

Install-Module -Name MSOnline

f:id:kazuakix:20180205210224p:plain
 
 あとは、Connect-MsolService コマンドレットでこれまで通り Office 365 に接続することができます。

$UserCredential = Get-Credential
Connect-MsolService -Credential $UserCredential

 ちなみに、二要素認証を使っている場合は単に Connect-MsolService とするだけで接続できます。(標準の Get-Credential と違って、何故か妙に縦に長いダイアログが表示されますね)

Connect-MsolService

f:id:kazuakix:20180205210928p:plain
 
 このあたりの詳細は Azure Active Directory の PowerShell モジュール の記事に記載があります。また、英語版のドキュメントではすでに正しく記載されていますので、日本語版ドキュメントもそのうち修正されると思います。

f:id:kazuakix:20180205211450p:plain

ASP .NET Core で作った Web API を Linux サーバーでホストしてみる

 Linux を使って ASP .NET Core を使ってみようとしてハマった事のメモです。

やりたかった事

 フロントエンドで接続を受け付けて、AP サーバーを呼び出す平凡な構成を考えてみます。インターネットからの接続を Nginx をリバースプロキシにして ASP .NET Core の Kastrel を呼び出します。

f:id:kazuakix:20180203160341p:plain

 この辺のドキュメントを参考に環境構築して、Windows で作った実行ファイルを Linux にコピーして実行してみました。
 
プロジェクトの作成

mkdir ShinjiLocation
cd ShinjiLocation
dotnet new webapi

f:id:kazuakix:20180203171748p:plain
 
実行ファイルの作成

dotnet publish -C Release

f:id:kazuakix:20180203170801p:plain
 

その 1) Windows と Linux のバージョンをあわせる

 Windows 作った空のプロジェクトを Linux で実行しようとしたところ、エラーが出てしまいました。

f:id:kazuakix:20180203171914p:plain

[root@ap01 ShinjiLocation]# dotnet ShinjiLocation.dll
Error:
  An assembly specified in the application dependencies manifest (ShinjiLocation.deps.json) was not found:
    package: 'Microsoft.AspNetCore.Antiforgery', version: '2.0.1'
    path: 'lib/netstandard2.0/Microsoft.AspNetCore.Antiforgery.dll'

 
 Windows で作ったプロジェクトと Linux で作ったプロジェクトを比較すると、.csproj で指定されているライブラリのバージョンが違っていました。
 
Windows で作ったプロジェクト

<Project Sdk="Microsoft.NET.Sdk.Web">
<PropertyGroup>
<TargetFramework>netcoreapp2.0</TargetFramework>
</PropertyGroup>
<ItemGroup>
<Folder Include="wwwroot\" />
</ItemGroup>
<ItemGroup>
<PackageReference Include="Microsoft.AspNetCore.All" Version="2.0.5" />
</ItemGroup>
<ItemGroup>
<DotNetCliToolReference Include="Microsoft.VisualStudio.Web.CodeGeneration.Tools" Version="2.0.2" />
</ItemGroup>
</Project>

 
Linux で作ったプロジェクト

<Project Sdk="Microsoft.NET.Sdk.Web">
<PropertyGroup>
<TargetFramework>netcoreapp2.0</TargetFramework>
</PropertyGroup>
<ItemGroup>
<Folder Include="wwwroot\" />
</ItemGroup>
<ItemGroup>
<PackageReference Include="Microsoft.AspNetCore.All" Version="2.0.0" />
</ItemGroup>
<ItemGroup>
<DotNetCliToolReference Include="Microsoft.VisualStudio.Web.CodeGeneration.Tools" Version="2.0.0" />
</ItemGroup>
</Project>

 今回は、Windows で作ったプロジェクトの Microsoft.AspNetCore.All と Microsoft.VisualStudio.Web.CodeGeneration.Tools のバージョンを Linux で作ったプロジェクトにあわせることで回避しました。

 この件について、後日 id:shibayan に聞いたところ、親切に .NET Downloads を見るように教えてくれました。

f:id:kazuakix:20180205214626p:plain

 確かに yum コマンドで確認すると、複数のバージョンが登録されています。

f:id:kazuakix:20180205215811p:plain

 インストールするとき、ドキュメントのサンプルそのままに古いバージョン (2.0.0) を指定してしまっていたのが原因でした。インストール前にはちゃんと最新バージョンをチェックしないといけないですね。
  

その 2) localhost 以外から Kastrel に接続できるようにする

 Linux サーバーで Web API が実行できるようになったので、リバースプロキシ経由でアクセスしてみようとしたのですが、別のサーバーから接続することができませんでした。

 設定項目らしきものも見当たらず、手詰まりになりそうだったので、アメリカに出張中の id:okazuki に助けを求めたところ、T ボーンステーキの画像と一緒に、以下の URL が送られてきました。

f:id:kazuakix:20180203164729p:plain

 どうやら、Program.cs にある BuildWebHost 関数の中で Kestrel に関するパラメーターを指定できるようです。

 早速、UseKestrel に Listen オプションだけを指定して UseStartup と Build の間に追加したところ、無事に別ホストのリバースプロキシ経由でアクセスできるようになりました。

public static IWebHost BuildWebHost(string[] args) =>
    WebHost.CreateDefaultBuilder(args)
        .UseStartup<Startup>()
        .UseKestrel(options =>
        {
            options.Listen(IPAddress.Any, 5000);
        })
        .Build();
    }
}

 
 とまぁ、こんな感じでようやく実行環境ができました。(Azure 使ってたらこんな事するまでもなかったんだとは思いますが...) あとは中身を作っていくだけですね!

Microsoft Teams で Adobe Creative Cloud のファイルを共有する

 Teams でファイルを共有する場合は OneDrive に置いておくのが普通ですが、昨年の Microsoft と Adobe の提携以降、Adobe Creative Cloud のファイル *1 も共有できるようになっています。

発表自体かなり前のもので今更感がありますが、実際に試してみました。
 

Teams の設定

 Teams の適当なチャネルのタブで + をクリックして、Adobe Creative Cloud のタブを追加します。

f:id:kazuakix:20180128142545p:plain

f:id:kazuakix:20180128142707p:plain

 デザイナさんの Adobe Creative Cloud の ID でサインインして、共有してもらうフォルダを選択します。

f:id:kazuakix:20180128142717p:plain
f:id:kazuakix:20180128142940p:plain
 
 タブに Creative Cloud のファイルが追加され、ファイルの表示、ダウンロードなどがおこなえるようになりました。

f:id:kazuakix:20180128143451p:plain
 
 OneDrive にアップロードしてくれれば普通に共有できるのに...とも思ったのですが、こちらで表示すると PSD ファイルのレイヤ表示などもできるようです。デザイナさんと共同作業するときは活用していきたいですね。

*1:デザイナさんは ”アセット” って言うんですね