【so what】 OpenWith って知ってます?

Windows 8 のコマンド系小ネタ その2です。 たぶん、99%の方が「ふーん、で?」と反応されると思いますが、微妙に楽しいコマンドなのでご紹介します。 例えば、readme.txt ファイルをダブルクリックすると通常はメモ帳が開きます。 メモ帳以外のアプリケーションで開きたい場合には、ファイルを右クリックしてコンテキストメニューから「プログラムから開く」を選択します。誰でも知っています。 では、バッチファイルの中からテキストファイルを開きたい場合を考えてみます。 通常は単純に以下のように書けばOKです。自動的に対応ずけられているアプリケーションで readme.txt が開きます。 readme.txt もしアプリケーションを指定したいのであれば、以下のように書くこともできます。 "%ProgramFiles%\Windows NT\Accessories\wordpad.exe" readme.txt では、開きたいアプリケーションをユーザーに選ばせたい場合にはどうしたらよいでしょう?(そんなニーズがどれほどあるかはアレですが) なんと、OpenWith.exe というコマンドが用意されています。 コマンドプロンプトから以下のように入力してみてください。 openwith readme.txt すると、以下のようにアプリケーション選択用のメニューが表示されます。 利用者は、このメニューから好きなアプリケーションを選択することができます。 とっても便利な機能のような気がするのですが、実は広い用途で使えるコマンドではないです。 でも知ってると、ちょっと自慢できます。


【Management】Windows 8 に .NET Framework 3.5 をインストールする、もう1つの方法 Fondue

コマンド系の小ネタをいくつか。まずは1つ目。 多くの方がご存知の通り、Windows 8 には既定では .NET Framework 3.5 がインストールされていません。 そして、これも多くの方がご存知の通り、インストールするには「プログラムと機能」から「Windows 機能の有効化または無効化」を選択して、おなじみの画面から「.NET Framework 3.5」をチェックします。 またはコマンドプロンプトから以下のコマンドを実行します。NetFx3 は .NET Framework 3.5 を表す機能名です。 Dism /online /enable-feature /featurename:NetFx3 /All 上記のいずれの場合も、Windows Update サイト(またはWSUSサイト)からファイルをダウンロードしてインストールしようとします。 もしネットワークが使用できず、Windows 8 のメディアからインストールしたい場合には、以下のように使用します。/Source はメディアのパス、/LimitAccess はWindows Updateに接続しないことを意味しています。 Dism /online /enable-feature /featurename:NetFx3 /All /Source:”D:\Sources\sxs” /LimitAccess もちろん、Windows PowerShell から実行することもできます(どちらかというと、こちらのほうが推奨されています)。 Enable-WindowsOptionalFeature -Online -FeatureName NetFx3 –All Enable-WindowsOptionalFeature -Online -FeatureName NetFx3 –All –Source ”D:\Sources\sxs”  -LimitAccess…

2

【Deployment】 WDS だけで Windows 8 を仮想マシンに自動展開するとキーボードレイアウトが英語配列(101/102)になってしまう

##2013.4.19 スクリプトを修正 Windows Deployment Service(WDS) で Windows 8 を仮想マシンに自動展開しようとすると、キー配列が英語(101/102)になってしまいます。そのため、初回ログオン時にキーボードドライバを 106/109 に変更しなければなりません。 何とかこの現象を回避し、日本語でインストールしようと試みているのですがなかなかうまくいかず試行錯誤しておりました。 本件に関し、MVP の 小澤 真之 氏が BLOG にて以下の記事を投稿してくださいました。 WDS で Windows 8 を展開する際に日本語キーボードを設定する http://engineermemo.wordpress.com/2013/04/11/wds-%e3%81%a7-windows-8-%e3%82%92%e5%b1%95%e9%96%8b%e3%81%99%e3%82%8b%e9%9a%9b%e3%81%ab%e6%97%a5%e6%9c%ac%e8%aa%9e%e3%82%ad%e3%83%bc%e3%83%9c%e3%83%bc%e3%83%89%e3%82%92%e8%a8%ad%e5%ae%9a%e3%81%99/ 要約すると、インストールに使用する install.wim ファイルに対して以下のコマンドを実行することで、既定のレイヤードドライバーを 106/109 に変更しておくという方法です。 dism /Image:C:\mount /Set-LayeredDriver:6 これならば言語ごとに install.wim を用意しておけば済むので、今のところ小澤さんが提案してくださったこの方法がベストだろうなぁ考えています。 が、そうはいっても別の(もうすこし変態的な)方法を考えたくなるのが人情というものです。 そこで、以下の PowerShell スクリプトを”インストール完了のタイミングを見計らってホスト側から"実行するってのはどうでしょう。※MDT 2012 Updat1 でタスクシーケンスを使用すれば、インストール完了後に実行できるかも ##仮想マシン名 $VMName = "test" ##設定したいLayeredDriver の値 $LayerdDriver = 6 ##仮想マシンの仮想ハードディスクのパスを取得 $HDD =…


【Management】DHCP フェールオーバーの構成が解除できない場合

Windows Server 2012 ではDHCP サーバーの構成をクラスタリングすることができることは、10万人位の方がご存知かと思います。 念のために簡単に紹介しておきます。 いままでの Windows Server DHCP サービスでは フェールオーバーすることはできず、1台の DHCP サービスが死んでしまった時のために、スコープを変えて別の DHCP サービスを用意しておく必要がありました。 Windows Server 2012 では、同じスコープを複数の DHCP サービスで共有し、ロードバランスならびにフェールオーバーが可能となりました。これにより、DHCP サービスの設計や導入が非常に楽になりました。 で、これはこれで便利なのですが、困ったこともあります。 一方の DHCP サーバーが死んでしまったとき、以下のようにスコープが消せないという問題が出ることがあります。 「スコープがフェールオーバーリレーションシップに含まれています。このスコープを関係から削除してください」 じゃぁ、ということで「フェールオーバーの構成解除」をしようとすると、以下のように「対象となるコンピューター上で、DHCP サーバーが実行されていません。」というエラーが出てしまい、にっちもさっちもいきません。   対象となるコンピューター上で、DHCPサーバー サービスが実行されていません。 フェールオーバーの構成を解除できませんでした。エラー: 1722 困ったときは Windows PowerShell です。間違いありません。 まずは、削除したいスコープのプロパティを開いて「フェールーバー」タブを確認しておきます。ここに書かれている「関係名」と「パートナーサーバー」をコマンドレットのパラメタとして使用します。 管理者モードで Windows PowerShell のコンソールを開き、以下の通りコマンドを入力します。 Remove-DhcpServerv4Failover -Name <関係名> –Force -Force を忘れずに指定してください。 警告が表示されることがあるのですが、フェールオーバー構成が削除されているはずです。 これで、スコープを削除することもできるようになっているはずです。  


【IAM】 DAC その 2 ~ なぜ企業のアクセス管理に DAC が必要なのか

前回の投稿は以下の通りです。 【IAM】 DAC その1 ~ グループベース RBAC の破たん? http://blogs.technet.com/b/junichia/archive/2013/03/29/3561744.aspx この投稿では、前回の投稿をふまえ、「なぜ企業のアクセス管理にDACが必要なのか」という点について書きたいと思います。 DAC が「Expression(式)ベースのルールによるアクセス管理」であることは前回の投稿で書いた通りです。 ここで疑問を持つ方がいらっしゃると思います。 「アクセスルールを管理するのは誰なのよ?」 当然の疑問です。 IDの属性を管理するのは「ID管理者」。リソースの属性を管理するのは「リソース管理者」です。両者を結び付ける「アクセスルール」を誰が管理するのか? 従来の ACL ベースのアクセス管理では、ルールを管理していたのは「リソース管理者(またはリソースのオーナー)」です。それが最も合理的であると考えられてきました。しかし、「社内統制」という観点では、しばしば不合理な問題が発生しうるのもこの方式です。 各所に IT が浸透し多く部門間でデータを共有するようになると、その取扱いが極めて煩雑になります。リソースの提供者の多くは「アクセス権の管理手法」を正確に理解していませんから、しばしば設定ミスや怠慢等によってセキュリティ上重大なリスクが発生してしまうことがあります。 こうした問題を軽減するために「企業レベルのアクセスルール管理」へのニーズが高まっています。企業内の専門部隊が、社内リソースのアクセスルールを集中的に管理するという考え方です。 もちろん、すべてのリソースがその対象となるわけではないでしょう。しかし、確実に社内統制が必要なリソースは存在します。そうしたリソースに対しては、統制されたアクセスルールを適用することで、これまでよりも安全にリソースを管理できるようになります。 ということで、冒頭の疑問への回答は以下の通りです。 「アクセスルールを管理するのは、社内のセキュリティチームである」 セキュリティチームがリソースのアクセス権に関して行う作業は以下の通りです。 1. 重要な社内リソースへのアクセス権に関してセキュリティポリシーを策定する 対象リソース:どのサーバーの、どういう属性を持ったリソースを対象にするのか 対象ユーザー:どういう属性を持ったユーザーを対象にするのか アクセスルール:対象リソースに対して対象ユーザーがどのようなアクセス権を持つの ここで注意していただきたいのは、対象リソースを明に(C:\Data とか)指定するわけではないということです。あくまでも対象となるリソースの「条件」を定義するのだという点に注意してください。 条件には、所属以外にも、担当プロジェクトや役職などが考えられますし、単純なところではデータの重要性(外部公開、社外秘、社員のみ など)を定義する必要もあるでしょう。また、より厳密に管理するのであれば「データがどういったコンプライアンスフレームワークに属するか」といった定義も必要になるでしょう。例えば以下のようなフレームワークが考えられます(日本にとっては重要でないものもあったりなかったりですが。。。)。 CObIT http://ja.wikipedia.org/wiki/COBIT EU Data Protection Directive(EU データ保護指令) http://www.caa.go.jp/seikatsu/kojin/H21report1a.pdf FACTA(外国口座税務コンプライアンス法) http://www.nri.co.jp/opinion/kinyu_itf/2011/pdf/itf_201108_6.pdf FERC/NERC CIP FISMA(Federal Information Security Management Act of 2002)…