Office365 Visio Pro for Office 365が Visio Online P2に改名されるようです。

Visio Web Accessが終了となったのはつい最近のことですが、今度はVisio Onlineのプレビューが終了となるようです。

というのも、Visio Onlineの販売が正式に開始されるからのよう。

今までVisioといえば、プロダクトのVisio 2016(Std/Pro)とVisio Pro for Office 365の2系統でしたが、Visio Pro for Office 365が2つに分離され、Visio Online Plan1とVisio Online Plan2とに分かれるようです。

Visio Online Plan2はVisio Pro for Office 365からの名称変更とのことなので、実質はVisio Web AccessSharePointより分離され、課金の一単位となったが正しい感じだと思われます。個人的にはVisioを単品で使っているケースをほとんど見てこなかったのですが、昔から単品で価格設定されていたりと、需要が様々なところであるんですかね。

2017年10月25日よりVisio + OneDriveの形で世に出てくるようなので、Visioサブスクリプション形式で利用していきたい方は提供開始を待ってみましょう。

音楽:はとどけい

Office 365 Proplus 1708と日本語の相性について

Office 365 Proplus(2016版)を利用しているケースで、業務アプリを作成している人は注意してください。

10/4に月次チャネルで1708がリリースされましたが、このバージョンは日本語を含むマクロを起動することができなくなっています。

【リリース状況(2017/10/4リリース)】

更新プログラム チャネル リリースのバージョン番号とビルド番号 - Office サポート

【日本語マクロが動作しない報告】

Office 2016 バージョン 1708 以降で日本語の VBA モジュール名を含むファイルを開くとエラー – Japan Office Developer Support Blog

【動作しないバージョン(1708 Build 8431.2079)】

f:id:mohessu:20171008134626p:plain

実際このバージョンではVBAの画面からモジュールが開けなくなり、Accessであれば「データベースに含まれている VBA プロジェクトを読み取れないため、データベースを開くことができません。」や、「式に指定した名前 が見つかりません。」などといったメッセージが表示されます。

【モジュールを直接開こうとした場合のエラー】

f:id:mohessu:20171008130724p:plain

【AutoExecでモジュールを起動させるケースのエラー】

f:id:mohessu:20171008132516p:plain

フォームと一体化したモジュール名称を持つものを準備するケースの多いAccessで問題が起こるケースが多いと思いますが、Word、ExcelOutlookVBAを用いるケースでは本現象が発生するため、今までと違う動きをするな。と思ったら本現象を疑うのが良いと思います。

本現象は月次チャネルで修正版モジュールが提供されています。
本現象で悩まされた方は月次チャネルの場合今すぐ更新を押下して更新するようにしましょう。

【今すぐ更新を】

f:id:mohessu:20171008141156p:plain

半期チャネル(対象限定)の場合、まだモジュールはなく、前のバージョンに戻すほかありません。以下内容を確認しながら切り戻しを行っていきましょう。

クイック実行版 (C2R/Click-to-Run) Outlook 2013/2016 の修正プログラムをアンインストールする手順について – Outlook Support Team Blog JAPAN

なんだか最近多言語関連の問題が多く発生しているように感じます。Officeだけでなく、Windowsも、、、

国際化が広く叫ばれ、i18nという言葉がもてはやされていた時代にはあまりこのような問題はきかなかった気がするのですが、これも時代が一巡したということでしょうか。

我々の言語が国際的に置き去りにならないように、注意していく必要がありそうです。

音楽:星の木馬

Azure 仮想マシンの強制再起動が行われるようです。

年一くらいのスパンなので、すでにあることを忘れている人が多くいるのではと推測するのですが、Azure IaaSにおいて、仮想マシンがメンテナンス再起動の時期になったようです。

[告知] 再起動を伴う仮想マシン メンテナンスのご案内 – Japan Azure Technical Support Engineers' Blog

メンテナンスは10月から順次開始され、Azureの規定に沿ってリージョンペアが片系ずつ再起動対象にされるとのこと。

なお今年のメンテナンスでは、バーチャルマシンを管理者のタイミングでバージョンアップする「セルフサービス」という機能が追加されています。

詳細はこれからとのことですが、仮想マシンの一覧にはメンテナンスという列が追加されており、メンテナンス可能期間に入ると再起動を行うためのボタンが配置されるとのこと。うまく利用することでユーザー影響を最小化できますね。

【Azure PortalVM)】

f:id:mohessu:20171007003404p:plain

ところで、今回のバージョンアップでAzureの基盤システムはWindows2016にバージョンアップするとのことです。

すべてのサーバーがWindows2016ベースとなることで、環境的にはDv3、Ev3でなくともネスト機能を利用できるようになるはず。
Azure IaaSの用途が拡大されるのではないかと期待ができますね。

音楽:トルキア

Office365 Exchangeの配送経路にはご注意を

Exchange Online。コネクタルールなどを多数設定されている方は、Exchangeの内部で配送されるケースと外部で配送されるケースの2パターンがあることを意識して組み立てることを忘れないようにしましょう。

一般的なメールシステムは、メールを送る際にMXレコードを見ながら送り先を決定します。しかし、Exchange Onlineでは、このMXレコードでの配送の前に内部配送を試すようなのです。

一般的に内部配送といえば、その境界は自社か否か。だと思うのですが、Exchange Onlineになるとその境界線がOffice365 に登録されたドメインか否か。になるようです。メールの送信先(To,CC,BCC)がOffce365の時はMXレコードを引きにいかない。ということのようです。(裏はとれていないのですが、おそらくそんな仕様になっていると思われます。)

今日はこの仕様に悩まされました、、、

Exchange Online、Office365て奥が深いですね、、、

音楽:ほうせんか

Office365にログインする回数が減るかもしれません。

Office365を利用されているかたは基本的に1日1回はログインをしていると思います。

人によってはブラウザを変えたり再起動をしたりで複数回ログインしているケースがあるかもしれません。

なにも意識していないと、毎度IDを入力し、パスワードを入力し、、、と、体にパスワードをしみこませちゃっている人も多いのではないでしょうか。

Office365では、そんな毎度の作業を減らすため「サインインしたままにする」チェックボックスがログイン画面に用意されていました。

【サインインしたままにするチェックボックス

f:id:mohessu:20171005022224p:plain

さらに最近はサインイン画面がバージョンアップする話も出ています。

Office365 新しいサインインページについて - ()のブログ

この新しいサインインページでは、さらにこの「サインインしたままにする」チェックボックスを後から表示に変え、このチェックを押してもらいやすくするように改良を加えるということを行うようなのです。

Fewer login prompts: The new “Keep me signed in” experience for Azure AD is in preview – Enterprise Mobility and Security Blog

新しいサインインページでは、ログインID→パスワード→サインインしたままにするか確認という3段階のフローでさらにログイン画面を見る回数を減らそうとしているようです。

上記サイトにどのような形になるか記載されています。現在は私のテナントではまだ対応がされていないらしく、サインインしたままにするチェックはパスワード入力画面についたままでした。

【新しいサインインページ】

f:id:mohessu:20171005021025p:plain

【パスワード入力画面にはサインインしたままにするチェックが付いています】

f:id:mohessu:20171005021124p:plain

この新しいページは10月の初旬には展開が始まるということなので、本当にそろそろこの画面が提供されるのではないでしょうか。

というわけで、MSもこのチェックをオンにすることを勧めていることがわかったかと思います。いまだにチェックを入れ忘れているという私みたいな人は、新しいページに切り替わるときにはこのことを思い出してパスワードを入力しない状態を謳歌してみてはいかがでしょうか。

音楽:セシルの庭

SharePoint Onlineのファイル更新日付の変更について

最近開発から遠ざかっていたので利用できるかいまいち不安でしたが、
ListItemのUpdateOverwriteVersionメソッド、今も利用できるようですね。

ファイルのバージョンを上げずに内容を変更する際に利用するメソッドとなります。

更新日時や作成日時を変更する際に利用したりもします。

ただ、最近のMSDNでは内容については一言も触れてもらえていない!

ListItem.UpdateOverwriteVersion method (Microsoft.SharePoint.Client)

 

というか、SharePoint開発者が減ったのか、最近のサイトで参考になる情報がほとんどありませんでした。

ので、自分備忘録で載せておきます。
まずは以下サイトからSDKをダウンロード。

Download SharePoint Online Client Components SDK from Official Microsoft Download Center

32bit、64bitの二種モジュールがあります。(私は64bitでPowerShellを動かすので64bitを導入しました。)

f:id:mohessu:20170813001401p:plain

ダウンロードしたらインストールまでは迷うことはないので割愛。

Windows PowerShellを起動して以下コマンドを流し込みましょう。


# PowerShellに読み込み
[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint.Client") | Out-Null
[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint.Client.Runtime") | Out-Null

# 各種定義
$url = Read-Host -Prompt "URLを入力してください";
$doclib = Read-Host -Prompt "ドキュメントライブラリ名を入力してください";
$user = Read-Host -Prompt "ユーザー名を入力してください";
# パスワード
$pas = Read-Host -Prompt "パスワードを入力してください" -AsSecureString;

# SharePoint Client Context インスタンスを生成
$credentials = New-Object Microsoft.SharePoint.Client.SharePointOnlineCredentials($user, $pas);
$context = New-Object Microsoft.SharePoint.Client.ClientContext($url)
$context.Credentials = $credentials

# リスト読み込み
$list = $context.get_web().get_lists().getByTitle($doclib)

# リスト情報
$context.Load($list)
$context.ExecuteQuery()
Write-Host "リスト名 : " $list.Title
Write-Host "リストタイプ : " $list.BaseType
Write-Host "作成日 : " $list.Created

# アイテム情報
$query = New-Object Microsoft.SharePoint.Client.CamlQuery
# 表示内容を制御しない場合は空文字をクエリーとして渡すこと
$query.ViewXml = ""
$ListItems = $List.getItems($query)
$context.Load($ListItems)
$context.ExecuteQuery()

foreach($item in $ListItems)
{
Write-Host $item.Id.ToString() `t $item["FileLeafRef"] `t $item["Editor"].LookupValue `t $item["Modified"]
}

# アイテム更新(1個目のファイルの更新日付を変更)
$updateItem = $ListItems[0]
# Modifiedを選ぶと更新日となります。この項にデータを入れて、、、
$updateItem["Modified"] = "2010/12/10 10:00:00"
# UpdateoverwirteVersion!これで今SharePointにあるアイテムのバージョンを上げずに更新日付のみを更新します。
$updateItem.UpdateOverwriteVersion()

$context.Load($updateItem)
$context.ExecuteQuery()

# アイテム確認
foreach($item in $ListItems)
{
Write-Host $item.Id.ToString() `t $item["FileLeafRef"] `t $item["Editor"].LookupValue `t $item["Modified"]
}

サイトはSharePoint でもOneDriveでも問題なさそうです。

音楽:i do

Windows10 Application guardの挙動を見てみました。

Application guard for Edgeですが、 いろいろ動かしていると不思議な面がちらほら。
この動きってどうなんだろう?と思ったところを上げてみたいと思います。

まずはWebノート。Application guardで作成したWebノートはApplication guard内で見えるように保存されます。

これは7月にお伝えした永続化設定が旨く効いているのだと思いますが、なぜかこの設定を有効にしていると、その他もろもろ永続状態が継続するようでした。

Windows10 Build 16232でました。 - ()のブログ

【Webノート】

f:id:mohessu:20171002081129p:plain

 ちゃんと紹介しようと思ったのですが、ローカルグループポリシーを変更して再起動したらエラーが、、、

残念ながら紹介が難しくなってしまいました汗

f:id:mohessu:20171003014731p:plain

永続を行っていたからなのか、ファイル選択画面からいろいろとファイルを弄ろうとみていたところ、タイムスタンプが7月から変わっておらずな状況でした。

なんとなくですが、Application guard環境ではWindows Updateなどが実施されないような、、(これは永続化がオンだからですかね?)

次のInsider Preview が入るころには再度動くようになっていると思うので、再度試してみたいと思います。

音楽:タバスコ