ActiveDirectory環境下でファイルサーバにWindows Serverを使っている場合、共有フォルダや自分専用フォルダを、Z:などのドライブに割り当てると便利ですね。
共有フォルダを割り当てるには、グループポリシーの「ユーザの構成→基本設定→ドライブマップ」を使うと簡単です。
自分専用フォルダを割り当てるには、まずそのフォルダを作成しないといけないので、ログオンスクリプトと使うと良いです。
準備
\\server という名前のサーバに、usersという共有フォルダ(Unixの /home に相当)を作っておきます。
一般ユーザが書き込める権限を付けておいて下さい。
スクリプトの設定
グループポリシーの以下の場所で、ログオンスクリプトを設定できます。
ユーザの構成 → ポリシー → Windowsの設定 → スクリプト(ログオン・ログオフ) → ログオン
ここのPowerShellスクリプトで、以下のような内容のファイルを指定すると、専用フォルダが作れます。
$user = $env:USERNAME
$dir = “\\server\users\$user”
if (-not (test-path $dir)) {
mkdir $dir
icacls $dir /inheritance:r /grant:r $user”:f”
}
net use z: $dir
ポイントは icacls の行です。
/inheritance:r を指定することで、親フォルダからの継承を外し、アクセス権を削除します。
そしてgrant:r を指定することで、自分だけはフルアクセス権を入手できます。
若干面倒ですが、これでセキュリティもOKですね。
(もっと良い方法があったら知りたい・・・)
ちょっとしたデータサーバ障害により、バックアップをしていなかった、C#で開発していたミニプログラムのソースコードが紛失してしまいました。
そこで Reflector.NETの出番!
exeやdllを読み込ませると、リバースエンジニアリングでC#の形に復元してくれます。
マシン語にコンパイルされるC++などと違い、C#は変数名やオブジェクト構造も維持するMSILにコンパイルされるため、精度は抜群。
コメントが消えたり、プロパティが get_* というメソッドに置換されたり、ラムダ式が展開されていたりするくらいで、ほとんど元のソースコードが復元できます。
むしろ面倒なのが、XAMLの記述やリソースファイルの配置だったり・・・
とにかくReflectorは便利ですね。
その分、読まれても問題ないコードを書くように気をつけないといけませんが・・・
ActiveDirectoryに参加しているマシンでは、デフォルトでActiveDirectoryへのログインを行います。
(入力したユーザ名は、ActiveDirectoryユーザ名として解釈されます)
ローカルアカウントにログインするには、マシン名\ユーザ名 または ユーザ名@マシン名 を使います。
しかし、長いマシン名の場合、毎回入力するのが面倒ですね。
そんなときのために(?)、
.\
という省略記法が存在するようです。
http://www.atmarkit.co.jp/fwin2k/win2ktips/1221lloglon/lloglon.html
早速、shinygoldというマシンを使う同僚に教えておきました。
これで、今後 lightgoldenrodyellow とか hecatoncheires などの長い名前を付けても安心ですね。
メインのシェルはコマンドプロンプトよりもPowerShellにしたいです。
同様に、ログオンスクリプトを書くのもPowerShellが便利です。
しかし、今まで当然のように使っていた %username% などの環境変数、PowerShellでは書式が違います。
うっかり %username% と入力すると、そのままの文字として解釈されてしまうのでご注意を。
書式は、 $env:環境変数名 です。
例:サーバの共有フォルダに自分の名前のフォルダを作成し、それをZドライブとしてマウントする
mkdir \\server\public\$env:USERNAME
net use z: \\server\public\$env:USERNAME
移動ユーザプロファイル周りをがちゃがちゃいじっていると、ログオンしたときに
一時ユーザプロファイルでログオンしています。
になってしまうことがあります。
これでは、データがどこにも保存されません。
ユーザプロファイルは、
・ユーザプロファイル一覧情報:レジストリ
・ユーザプロファイル実データ:C:/Users以下
に保存されるため、ファイルだけ削除するとこの現象になります。
解決するには、http://support.microsoft.com/kb/947215/ja を参考に
・C:/Users/ 以下で、いらないフォルダを削除
・コンピュータのプロパティ→詳細設定→ユーザプロファイル で、いらないプロファイルを削除
・ユーザアカウントの管理で、いらないユーザを削除
・HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList 以下の、削除したユーザに対応しているキーを削除
これらを実施します。
この後再起動すれば、ユーザを作成・初回ログインする前の状態に戻るので、再度デフォルトプロファイルが読み込まれます。
レジストリを削除する際は、うっかりローカルの管理ユーザなどを削除しないように気をつけてください。
Windows Vista以降では、PowerShellが標準搭載されています。
慣れてくると、コマンドプロンプトよりもPowerShellの方がいろいろ便利です。とりあえず、うっかりlsと打っても大丈夫なのが一番重要。
ただし、起動手順は
・コマンドプロンプト: Windows + R → cmd
・PowerShell: Windows + R → powershell
このように、powershellと打ち込むのがめんどくさいですね。
そこで、ファイル名を指定して実行のショートカットに追加してしまいましょう。
C:/Users/baba/shortcuts などのフォルダを作り、その中にPowerShellへのショートカット「ps」という名前で作ります。
ps → C:\WINDOWS\system32\WindowsPowerShell\v1.0\powershell.exe
後は、環境変数のPATHにC:/Users/baba/shortcuts を追加すればOKです。

環境変数のPATHを設定
これで、Windows + R → ps でPowerShellが開くため、コマンドプロンプトを使う機会が減りそうです。
ショートカットを作成する際、作業フォルダを指定できるのもポイントですね。
もちろん、PowerShell以外にもショートカットおき放題なので、ランチャーいらずです。
バージョン情報と一口にいっても、実行ファイルのバージョン、DLLのバージョン、ClickOnceやインストーラのバージョンなど様々です。
バージョン情報ダイアログを作るために、これらのバージョンの取得方法を書いてみます。といってもコードで。
/// <summary>
/// ClickOnceで設定されたバージョンを取得
/// </summary>
public static Version ClickOnceVersion
{
if (!System.Deployment.Application.ApplicationDeployment.IsNetworkDeployed)
{
return null;
}
return System.Deployment.Application.ApplicationDeployment
.CurrentDeployment.CurrentVersion;
}
/// <summary>
/// 実行中のexeファイルのバージョンを取得
/// </summary>
public static string AssemblyVersion
{
return System.Windows.Forms.Application.ProductVersion;
}
/// <summary>
/// 実行中のexeファイルと同一ディレクトリにあるDLLの情報を取得
/// </summary>
public static List<System.Diagnostics.FileVersionInfo> DllVersion
{
var versions = new List<System.Diagnostics.FileVersionInfo>();
//自身のファイルパスを取得し、同一ディレクトリのdllファイルを一覧する
string path = System.IO.Path.GetDirectoryName(
System.Windows.Forms.Application.ExecutablePath);
foreach (string name in System.IO.Directory.GetFiles(path, "*.dll"))
{
System.Diagnostics.FileVersionInfo info =
System.Diagnostics.FileVersionInfo.GetVersionInfo(name);
versions.Add(info);
}
return versions;
}
このような感じで、バージョン情報ダイアログが作れそうです。
※DLLのバージョン取得はもう少し工夫しないと問題がありそうですが・・・
C#等のアプリで、自身がClickOnceでインストール・実行されているかをチェックするには、
System.Deployment.Application.ApplicationDeployment.IsNetworkDeployed
を調べます。
しかしこのプロパティ、普通に起動するとfalseが取得できますが、Visual Studioから起動するとなぜかフリーズすることがあります。ありました。
この場合は、ClickOnceアプリの実体が保存される C:/Users/ユーザ名/AppData/Local/Apps/2.0 を削除して、コンピュータを再起動すると直るようです。直りました。
起動プロセスが複雑になるとたまに面倒ですね。
プログラムをインストールする際などは、管理者権限が必要です。
どういう環境依存だかわかりませんが、
ActiveDirectoryでUAC無効の環境で一般ユーザとしてログインしている状態で
プログラムを右クリック→管理者として実行 しても、無視されて一般権限で実行されてしまいました。
この場合は、Shiftキーを押しながら右クリックして、「別のユーザをして実行」をすれば、管理者のログインIDを入力して実行できます。
もちろん、コマンドプロンプトで「runas /user:administrator」を使っても良いですが、コントロールパネルの項目(.msc)などはこれで開けない場合もあるので、両方覚えておけば便利です。
ActiveDirectory環境で、一般ユーザがクライアントPCでパスワードを変更するには、Ctrl+Alt+Deleteを押します。
ここでパスワードの変更を選べばパスワードが変更できるはずですが、
パスワードを変更できませんでした。新しいパスワードとして指定された値は、パスワードの長さ、複雑さ、または履歴に関するドメインの要件を満たしていません。
と言われてしまうことがあります。
この場合は、以下を試してみます。
「Windows2008」などの、複雑さの要件を満たすパスワードを入れてみる
これでOKなら、グループポリシー「パスワードは複雑性の要件を満たす必要がある」が原因です。
嫌なら、これを無効にします。
これでもだめなら、「パスワードの変更禁止期間」が邪魔をしている可能性があります。
デフォルトでは、1週間程度のパスワード変更禁止期間が設定されていて、1日2回変更しようとすると上記のエラーが出るようです。
Default Domain Policyなどで「パスワード変更禁止期間」を0日に設定すれば直りそうです。
どういうわけだか、パスワードのポリシーだけはドメインコントローラーのポリシーが適用されることもあるような、そんな挙動をするので、Default Domain PolicyとDefault Domain Controller Policyの両方で
・パスワード変更禁止期間 → 0日
・パスワードの履歴を保存する → 無効
と設定しておくと良いと思います。
もちろん、ユーザの設定で「ユーザはパスワードを変更できない」にチェックが入っていないか確認し、gpupdate /force を実行するか再起動しておく必要があります。