WhitePotageのブログ

ミント菓子はかっらーいのがイイんだよねと思っている人

他のメールボックスを追加すると解除できない…という状態を直す話

Office365 Outlook

Office365のプラン + Outloook2016 のユーザーAがいたとします。
このユーザーは、別の（自分以外の）メールボックスBに対するフルアクセス権もあるとします。
まあ、企業だと普通にそういうのはありますね。　部門で受ける共有メールボックスとか。

で、このユーザーAが、Outlookに設定を追加し、メールボックスBをフォルダーとして参照できるようにした。
これも普通にやりますね。普段の自分のメールを見ながら、他のボックスへの着信もきちんとチェックしたいという。

Office365 ブラウザ版のOutlookは簡単に追加、解除できる

メールボックスBをフォルダーとして表示するには、トップフォルダーで右クリックして「共有フォルダーの追加」と進みます。
結果はこんな感じ
f:id:WhitePotage:20161217180634p:plain

普通～。

アクセスが不要になったら、表示状態を解除するのも簡単です。
フォルダーとして追加したメールボックスを右クリックし、「共有フォルダーの削除」とやればいい。

f:id:WhitePotage:20161217182205p:plain

同じ操作をOutlook2016で行うと不幸になる

ところで、ユーザーAはブラウザが嫌いで、Outlookクライアントが大好きだったとする。
フォルダー追加時の操作はブラウザ版と大体同じで、「ファイル→開く→他のユーザーのフォルダー」と進めばOKです。

では、削除してみましょう。
軽い気持ちで、追加したフォルダーを右クリックすると…

「このフォルダーのグループは、電子メールアカウントに関連付けられています。
　アカウントを削除するには、[ファイル] タブをクリックし、[情報] タブの [アカウント設定] をクリックします。それから、対象の電子メールアカウントを選択して[削除] をクリックします。」

…何か変なことを言われます。
ユーザーAが行ったのは、「他のユーザーのフォルダーを追加」であって、アカウント設定から電子メールを追加しているわけではない。
指示通りにしようとしても、該当の削除対象がなく、操作できないのです。
そんなわけで、共有フォルダーの追加には罠がありました。　Outlookからは一度追加すると絶対に削除できないメールフォルダー…　ってなんだそれ？

この状況を解決する方法

ムカついたのでサポートに聞いてみました。
方法を聞いて更にムカつきましたが…。　まあ、消す方法がわかったので書いておきます。

A)　メールボックスBから、ユーザーAのフルアクセス権限を削除
B)　(ユーザープロファイル)\AppData\Local\Microsoft\Outlook\16\AutoD.（メールアドレス）.xml
　　にて、削除したいメールボックスの「<AlternativeMailbox>～</AlternativeMailbox>」を削除
　　さらに、同じ場所の AutoD.(削除したいメールボックスのアドレス).xml を削除

Aは必須ですが、ユーザーがオフラインだと効かないので、そんな人に騒がれた場合は応急措置でBを併用。
Bを行うと、Outlook起動時に問題のメールフォルダーがいなくなります。オフラインの間だけ。
しかし結局Aを行わないと、オンラインになるたび何度でも復活します。なんだそれ…。
操作性でOutlookが負けて、ブラウザが勝つ時代が来るとは思わなかった。

ちなみにAは Exchange 管理センターからの操作になるので、権限がない場合は人を呼んでください。
「AB両方実行したのに、まだフォルダが見える！」　となってしまった場合は、なんとそのまま起動していると…あるときフッと消えます。本当になんだそれ。

Outlookのメールボックスが復活する理由

追加するまで現れないくせに、一旦追加すれば普通に消せず、PCの設定ファイルから削除しても、頑として復活するメールフォルダー。
なんでブラウザと同じじゃないんですか？　と、再びサポートに聞いてみました。

結果、復活の理由は OutlookとExchangeサーバーに備わった Automapping 機能だそうです。
Office365のメールサービスである Exchange は元々、権限のある別のメールボックスを自動検出・表示させる機能 (Automapping) を持っていて、当初はなんでも無差別に表示させて問題を起こしていたようですが、その後改良の歴史をたどり、現在の手元動作では「フルアクセス権限のあるフォルダを、自分で追加した場合に、マッピングを維持する」機能として残っています。
だから、クライアントからはマッピングを消せない。
Automapping から逃れたければ権限を抜けと（笑）

「もし、権限を抜かずにフォルダを削除したい場合は」と、更にサポートは教えてくださりました。
フルアクセス権限を普通につけるのではなく、Automappig機能抜きでアクセス権をつけると良いそうです。
すなわち、PowerShellで

> Add-MailboxPermission -Identity "Bのメールボックス" -User "Aのユーザー名" -AccessRights FullAccess -AutoMapping $False

…　いちおう逃れる方法はあるようですね。　
即時反映ではないので、気長に待てるタイミングで実行。
既にフルアクセス権限がある場合も、コマンドを再実行することで （既に設定済みという警告が出るけど）Automapping機能が無効になります。

無効になった後は、先ほどのXMLファイルを忘れず編集することで、それ以降復活しなくなるという。 何か副作用ありそうだけど検証したくないので目をつぶるよ。
そして、右クリックで削除はできない。　ブラウザ版は削除できる。
ふう～ん…。

なんか、いかにももうちょっと、あとほんのちょっとで同じにできそうな印象なんだけど～…。
365チームはお互いもっと連携すればいいと思いまーす。

 

スポンサー

昔の○○奉行をインストールしたかったからSQL Server 2008 R2 SP1をスリップストリーム

パッケージソフトにSQL Serverが同梱されていることがあります。
たとえば○○奉行とか。　奉行ネットワーク版とか。　特に恨みはありませんが奉行とか。
そういう場合、インストールという行為はSQL Serverをインストールすると同時に、アプリケーションの動作に必要な一切をダバァァァと自動構築して戴く行為なわけで、エンドユーザーに介入の機会はありません。
なので、インストールメディアに同梱されているSQL Serverが大層古くてサービスパックが当たっていないとしても、セットアッププログラムを取り替えるわけにはゆかんのです。

困るじゃん…。
だって。　Windows Server 2008 R2 SP1以降の新しいサーバーに対して、SQL Server 2008 R2の初期バージョンは新規インストールできないのよ奥様。
あらかじめSP1の適用されたメディアがないと、インストールが失敗するんですのよ。

そんなこと言われたってぇ…orz
新しいサーバーに古い奉行をインストールししたい時だって、あるじゃない…。

というわけで、奉行（まだ言うか）のインストールメディアを改訂してみました。
要は、奉行の全自動構築処理を損なわないまま、セットアッププログラム進行中にキックされる SQL Server インストーラーがサービスパック適用状態になっていればいいんでしょ。
これを実現するには、該当フォルダの中身を改廃し、SP1以降でサポートされる「スリップストリーム方式によるインストール」の状態にします。

SQL Server 2008 に関しては、公式のサイトに 完璧なまとめ があったので、別にブログすることもないわーと思ったのですが、今回実行したかった SQL Server 2008 "R2" では若干フォルダが異なったりしたので、一応メモっておくことにしました。
モチロン、奉行でなくても単体のSQL Server 2008 R2をインストールしたい場合にも有効です。

このブログが適応する事例

もし、SQL Server 2008 R2を Windows Server 2008 R2以降に新規インストールしようとしていて、SP1適用済みのイメージを入手できない環境で、下記のようなエラーで失敗してしまう場合は、後述の方法で修正できます。

エラーその１
　SQL Server 2008 R2 Standard Editionのセットアップ中にエラーが発生しました。
　Exit Code (Decimal) : -595541211
　Exit facility code : 1152
　Exit error code : 49957
　Requested action : install

エラーその２
　SQL Server 2008 R2 Standard Editionのセットアップ中にエラーが発生しました。
　Exit Code (Decimal) ; -2068119551
　Exit Facility code : 1211
　Exit error code : 1
　Requested action : install
　Configuration error code : 0xD3BEBD98@1211@1
　Configuration error description: 1つ以上のコマンドラインスイッチが無効です

修正方法（インストールフォルダの改廃）

この改廃により、無印のインストールメディアにSP1を設置し、「インストールとSP適用が同時に行われる」状態にします。

１．準備
  • メディア一式をサーバー内のHDDに全部コピー
    ここでは便宜上、「c:\bugyo」とします。別に恨みはない。
    メディアを全部コピーしたなら、「c:\bugyo\SQLSETUP」が SQL Serverのセットアップフォルダです。
    俺は奉行じゃないぞー、という場合は、元々のセットアップフォルダに読み替えて。

  • SQL Server 2008 R2 SP1のダウンロード -> c:\bugyo\sp1
    下記3点をダウンロード。　使わなくても必ずダウンロード。（らしい。）
    日本語環境じゃないOSなら、末尾の国コードをそれなりに変更して。
    SQLServer2008R2SP1-KB2528583-IA64-JPN.exe
    SQLServer2008R2SP1-KB2528583-x64-JPN.exe
    SQLServer2008R2SP1-KB2528583-x86-JPN.exe

  • このサーバー用のファイルを展開し、セットアップサポートファイルを導入
    スリップストリーム方式はSP1以降の機能なので、SP1のセットアップサポートファイルがあらかじめインストールされた状態にします。
    先の3ファイルのうち、赤文字の部分を自分のOSにあわせて実行してください。
    > SQLServer2008R2SP1-kb2528583-x64.-JPN.exe /x:c:\bugyo\sp1
    > c:\bugyo\sp1\1041_jpn_lp\x64\setup\sqlsupport_msi\sqlsupport.msi
    　→「Microsoft SQL Server 2008 R2 Setup（日本語）」がインストールされる
２．仕込み開始 
  • 元のイメージに追加する形でSP1を展開
    元のインストールとは別に、「c:\bugyo\SQLSETUP\PCU」以下にSPを展開するコマンドです。
    自分のOSで使わなくても、3種類全部の展開を実行。
    > SQLServer2008R2SP1-kb2528583-x64.-JPN.exe /x:c:\bugyo\SQLSETUP\PCU
    > SQLServer2008R2SP1-kb2528583-ia64.-JPN.exe /x:c:\bugyo\SQLSETUP\PCU
    > SQLServer2008R2SP1-kb2528583-x86.-JPN.exe /x:c:\bugyo\SQLSETUP\PCU

  • setup.exeの置き換え
    > robocopy c:\bugyo\SQLSETUP\PCU c:\bugyo\SQLSETUP setup.exe
    > robocopy c:\bugyo\SQLSETUP\PCU\resources\1041 c:\bugyo\SQLSETUP\resources\1041 setup.rll
    　→それぞれ、「2010/4/4」のファイルが「2011/6/17」に置き換わる

  • インストールファイルの置き換え
    なんか自動改行されてますが…、それぞれ1行で入力します。全部で3行。
    > robocopy c:\bugyo\SQLSETUP\PCU\x64 c:\bugyo\SQLSETUP\x64 /XF Microsoft.SQL.Chainer.PackageData.dll
    > robocopy c:\bugyo\SQLSETUP\PCU\ia64 c:\bugyo\SQLSETUP\ia64 /XF Microsoft.SQL.Chainer.PackageData.dll
    > robocopy c:\bugyo\SQLSETUP\PCU\x86 c:\bugyo\SQLSETUP\x86 /XF Microsoft.SQL.Chainer.PackageData.dll
    　→ /XF で指定されたdllを除くファイルが置き換えられる

  • セットアップ中にSP1が読み込まれるようにする
    先の手順の3つのフォルダにある「defaultsetup.ini」を編集し、セクションの末尾に
    「PCUSOURCE=".\PCU"」を追加。
    フォルダが3つあるので編集も3回だよ。　　
３．実食 

これで、SQLサーバーのインストーラーが実行される際にSP1が適用されるようになりました。
この部分を含む、「c:\bugyo」配下のフォルダ（SQLSETUP部分が置き換わったもの）で、普通に奉行オリジナルのsetupを実行すると…

インストールが正常終了するようになったよ！

 

スポンサー

W10 Home で 「このアカウントは無効になっています。システム管理者に問い合わせてください。」 からの回復が難儀だった話

高齢の親がパソコンで困っていたわけです。
どうやら自分のアカウントの管理者権限を失っていました。
Windows10 Home。勝手にアップデートするアレを抑止できずにやられちゃった系。

一人しかいないユーザーに、管理者権限がない。
経緯はともかく、定番はセーフモードだねと思ったら…　それが地雷だった！
Proユーザーの自分が疑いもしなかった対応の数々が、Homeには通用しなかったのです。

起きてしまったこと 

  • 起動後、「このアカウントは無効になっています。システム管理者に問い合わせてください。」だけが表示され、ボタンもなくキーシーケンスもきかない。
  • この状態になったら、電源を切る以外に何もできない…　詰み。

なんでこうなったのか

まず、Win10 Homeの標準仕様はこうです。

  • ログオン（サインイン）ユーザー選択画面は無く、最後にサインインしたユーザーで自動的にサインインされる
  • コンピュータの管理画面に「ローカルユーザーとグループ」が無い
  • 起動時にセーフモードを選択することはできない
    ＊セーフモードにするには、サインイン中にその指定をしてから再起動する

この状態でセーフモードを使用し、うっかり再起動してみなはれ。
セーフモードでは、パスワード無しのAdministratorで自動的にサインインされている。
再起動後はセーフモードが解除され、Administratorは無効になる。
だが！　奴は前回サインインしたユーザーで自動的にサインインするッ！
つまり…　わかるな？
「このアカウントは無効になっています。システム管理者に問い合わせてください。」

あー、ふざけんな、と。
間違いなく仕様不備ですよ、と。

え、もう一回セーフモードにすればいいんじゃないかって？　無理。
一度ログインしないとそれは提供されず、今まさにログインできないからです。

回復方法（Windows10 1511 Home)

もしこのWindowsが7なら、何も困らなかった。
起動時にF8キーを連打し、再びセーフモードに入ればよいのです。

もしこのWindowsが10 Proなら、こうなる確率はとても低かった。
「ローカルユーザーとグループ」を迷い無く操作し、好きにすりゃーよいのです。

だが、Homeにそれが無いなんて知らなかった、対処に迷って再起動したら詰んだ、という御方がいたら（自分だけど）、リカバリを決断する前に下記をお試し下さい。

  1. セーフモードで起動できるようにする（要製品CD)
    ログイン手段のない今、セーフモードにするにはメディアブートが必要です。
    Win10のCDかUSBを、探すなり作るなりして、そこからブートしてください。
    その後、
    ①「コンピューターを修復する」
    　→「トラブルシューティング」
    　→「詳細オプション」
    　→「コマンドプロンプト」
    　と進みます。
    　メディアメーカにより若干違うので、雰囲気であわせてください。
    ②このプロンプトは、メディア上のWindowsPEで起動しています。
    　直したいPCのシステムドライブをカレントにしてください。
    　このモード中に限り、Cドライブとは限りません。
    　> cd (ドライブ名):
    　> dir または、> dir \user
    　と入力し、自分のPCにあるべきフォルダやユーザー名が出るまで
    　ドライブを切り替えてカレントにします。
    ③次回起動時のふるまいを書き換えます。
    　> bcdedit /set {default} safeboot minimal
    　「safeboot minimal」はセーフモードを指定したことになります。
    ④コマンドプロンプトを終了して再起動
    　> exit
    　でプロンプトを終了すると、オプションの選択画面に戻ります。
    　ブートメディアを取り出し、「続行」で再起動してください。
    　→　すると、PCがセーフモードで起動します！

  2. Administratorを有効にする、その他ユーザーの不具合を直す
    ともかく、次回起動時にAdministratorが自動選択される状況をやり過ごすため
    Administratorを有効にします。コマンドで。
    だって、HomeにはこのためのGUIがないんだからね！
    > net user Administrator /active:yes

    ついでに、ユーザーの失われた管理者権限を復活するにはこれ。
    > net localgroup Administrators (ユーザー名) /add
    これで、ユーザーに管理者権限が付与されます。

    最後に、次回起動時のふるまいを元に戻します。
    > bcdedit /deletevalue {default} safeboot
    これを実行しないと、永遠にセーフモードで起動し続けるよ (^^;)

    ここまで実行したら、再起動。

  3. 起動ユーザーをAdministratorからいつものユーザーに戻す
    さて、無事に起動したなら、Administratorで自動サインインされているはず。
    サインアウトして、通常ユーザーに切り替えてください。
    これで、次回からは和やかな起動が得られることでしょう…　やれやれ。

  4. Administratorを再び無効にする
    いや、別に有効のままでもPCは使えますけど。
    自分ならパスワードをかけて有効のままにしておきますけど。
    でも、ねぇ。　利用者がビギナーの高齢者です、となるとやっぱり。
    > net user Administrator /active:no
    ってことにしておきましょうか。

最後に

この現象に遭ったWindows10のバージョンは、2015年10月のTH2 1511です。
関係あるかわかりませんが、パスワード無しでマイクロソフトアカウント不使用。
最新の1607 Homeはどうなのかなー…。
この現象がこっそり修正されて、セーフモードのAdministratorをノーカンにしてくれたなら、MS様のエンドユーザー対応をちょっと見直すかもしれない。　別に検証したくないけど。

 

スポンサー