2017年 10月 26日
Windows10 手動で ISOファイル から Fall Creators Update にアップデートする
まだ真新しい、Windows Creators Update のＰＣを Fall Creators にISOファイルから直接バージョンアップしました。回線がそれほど太くないので、ISOをダウンロードして確実にオフラインでもアップデートできれば、回線に関わるコスト（時間）が短縮できるし、台数が多い場合もそれだけ手早くできるので、ISOからのアップデートはお勧めです。
前回のはこちら
ISO を使った Windows 10 のオフラインアップデート
- 準備するもの -
- ヒマでブラウザでＳＮＳなんかしないまた―りとした夜 -> 寝ている間の ISO のダウンロードに必要- 何もすることがない雨の週末の金曜の午後 -> 作業時間は２～３時間、徹夜も覚悟のその間ＰＣは使えない。- Blue Noteの CD ２～３枚 -> アップデートする時のＢＧＭが必要- チャンドラーの短編集２～３冊 -> これくらいは読み終えるくらい時間がかかる- 缶ビール２～３本 -> ま、失敗したら徹夜覚悟ですな。- バーボンのボトルがあれば直良し- アイスクリーム -> あまり腹を冷やすと逆効果- チョコチップス -> バーボンに合う、腹減るからね。
- ISO の入手先-
Windows 2017 Fall Creators Update ISO ファイル
ダウンロード先
"ツールを今すぐダウンロード"
ダウンロードした MediaCreationTool を起動
なにやらやっている
よーく読んで”同意”するしかない。
"別なPCのインストールメディア ....."を選んで ISO ファイルを手に入れる。
"このPCのお勧めのオプション"のチェックを外す
アーキテクチャ”64”または"32"必要であれば、両方
”プロダクトキーが要るよ”のダイアログを確認
使用するメディアは "ISOファイル"を選択
保存先が指定できるので、Ｃ：ドライブの空きを考えて、別ドライブか、ネットワークに保存するのが良いでしょう。
デフォルトファイル名が Windows10.ISO なので HOME 版なのか Pro 版なのか、３２ビット版なのか、６４ビット版なのかわかるように、ファイル名に名前を付けて保存
一晩寝る。ZZZZzzzzzz.......
この間 Youtube なんかは見ない事。
- いよいよアップデート -
余分なソフトウェア、機能は停止させておくこと。
このＰＣには Hyper-V が動作していたので、削除しておきました。以前 Anniversary アップグレードした時はこいつが原因で、失敗したことがあります。また、Windows と Linux のデュアルブートしているＰＣもおかしなことになる可能性があります。Linux の Grub が書き換えられてブートできなくなる場合があります。アンチウィルスは削除しませんでしたが、時折悪さする事が、悪さどころかシステムをクラッシュさせる場合もあるので、削除した方が無難でしょう。他に常駐系のアプリケーションは、削除するなり、サービスを無効にしておくことが、安全にアップデートする秘訣でしょう。どうせ Microsoft 製品ですから、素の状態でしかテストしていない、そんなものです。
ISO ファイルをマウントして
> setup.exe を実行します。
回線の都合を考えて、この時点では更新のダウンロードはしないで、別な機会にしましょう。
「インストールの品質向上に協力」する必要なんてないので、チェックは外します。何を送信するか、判りませんからね。
嫌々ながら「同意する」
何かと、リフレッシュインストールしたがるけれど、個人用ファイルとアプリは引き継ぎます。
インストールしています....... 30 分
勝手にリブートします。ノートブックなので Bios のパスワードを入れないと起動できない。
構成中 ..... ３０分
もう一度再起動、また Bios のパスワード
構成中 .... 30 分
またまた再起動、またか。
構成中.... 30 分 起動できた。
プロファイルの再構築 約５分
終わり、> winver でバージョンを確認 Version 1709 Build 16299.15 でした。
その後 Windows Update をします。
- インプレッション -
今回は何のドラマもなくアップデートが終わりました。Windows10 というものの変化を見ていると、Windows10 が如何に未完成で、未熟なものであるのかというのを身に染みて感じます。これから、どんな便利な機能が亡くなってしまったか、どれほど不便になったか、どれだけ先取りして、使えない邪魔な機能が増えたのかをチェックしてみます。
また、せっかく見つけて Disable にした機能が復活している場合があるので、これも要チェックですね。
Windows7 からWindows10 にアップデートしたらまずするべき事。
「Windows10 をエンタープライズ利用する」場合、単に"Windows10" という言い方をしてはいけない状態になります。当然多くのPCの償却期間、４～５年の期間を見越して、どのバージョンを選ぶかが重要になります。 "Windows10 xx update" と "Windows10 yy update" は別物の製品です。今 Internet Explorer 11 が付いてきているようですが、このサポートも、これからの長い "Windows10" 時代に終了するはずです。何しろ "Windows10" は最後の Windows です。 今後何年続くかわからない代物なのです。
ユーザが自分自身でアップデートする可能性は少ないでしょうから、人力でどこかのタイミングで、償却と共に、バージョンアップを検討しなければならないでしょう。そのタイミングを間違えると、エラク不便な事になります。
また、 Windows10 自体のアップデート作業は１台当たり２～３時間はかかる作業です。その間にどれだけユーザの生産性を削ぐかを検討しなければなりません。人海戦術で行っても、一人当たり一日５～6台が限度です。ライセンス費用だけではなく、作業コストと、作業中に生産性を削ぐ時間のコストを考えると、１台当たり、2～３万円程度の費用、あるいは利益機会の損失があります。
パッチを充てる程度の手間と思うと痛い思いをするでしょう。
次の読み物
openSUSE シェルを Windows10 Subsystem for Linux (WSL) で使うOES Linux でフォルダの容量制限付きアーカイブ専用ファイルサーバー：サーバーをゴミ箱にしない工夫ファイルサーバーのフォルダ容量制限(ディレクトリクォータ)
- Keyword -
Windows10 Fall Creators Update, Version 1709, 1803, ISO マウント, ISO アップデート, インストール手順, アップデート手順, 作業時間
▲
by islandcenter
| 2017-10-26 15:30
| Windows
|
Trackback
|
Comments(0)
2017年 10月 19日
Windows10 GPOでドライブを非表示にする。
Windows10 GPOでドライブを非表示にする。
１０年前にこんな記事を書いたのですが、未だにご覧になられる方がいらっしゃるようで気になっていました。
グループポリシーでドライブを非表示にする。
という事で、 Windows10 でも、エクスプローラからドライブが非表示にできるかどうかを試してみました。
Windows のドライブは勿論、アルファベットのA～Zまであるのですが、意図的に見せたくないドライブもあります。例えばC:ドライブに勝手にディレクトリを掘って、そこに重要なデータを保管されたりすると、いざ、PCがご臨終になった場合に、データが無くなったとウルサいエンドユーザさんもいるわけですね。できれば、C:とD: は別なパーティションにわけて、D:ドライブは自由に使ってもいいけどC:ドライブは、システムを復旧した時に保証されないよ、という事もあるわけです。ついでに、ドキュメントフォルダなんかはD:ドライブに割り当ててあげて、タスクスケジューラなんかでD:ドライブだけをNASなどの隠しドライブに Robocopy してあげれば、最低限ユーザのデータのバックアップは為せば成る。
また、USB記憶装置なんかをつないだ時に、ドライブレターが、エクスプローラに表示されなければ、簡単にコピーすることもできません。「なぜコピーできないんだ」と言われれば、それは「セキュリティポリシーだから」で済むわけです。そこで、例えばネットワークに割り当てたP:とかS: とか以外は見せたくないという事も考えられるわけです。
という事で、エクスプローラから、見せたくないドライブを隠してしまおう Windows10 版です。もっとも、エクスプローラからは見えないだけで、コマンドプロンプトや、保存したり、エクスプローラから、開く時のアドレスバーに直接ドライブ名を入れてしまえば、見えてしまうのですが、おおよそ９割のエンドユーザさんはそんなことお構いなしに「見えないものは無いもの」と考えてくれるわけですから、それなりに便利だともいえます。
- 基本編 -
さて、グループポリシーエディタ gpedit のドライブを隠す設定は
- [ユーザーの構成]、[管理用テンプレート]、[Windows コンポーネント]、[エクスプローラー]
- [指定したドライブを [マイ コンピューター] 内で非表示にする] を開く
- [指定したドライブを [マイ コンピューター] 内で非表示にする] ダイアログ ボックスで [有効]
- ドロップダウン ボックスで該当するオプションをトグルして設定
という手順になるのですが、
ただ、この gpedit のテンプレートでは、決め打ちのドライブを隠す設定だけなので D: とネットワークに割り当てた P: と S: だけは見せたいとかのカスタマイズができません。という事で、この「隠しドライブ」のテンプレートをカスタマイズしてみましょう、というのがテーマです。
- 不可視ドライブをカスタマイズする -
C:\Windows\PolicyDefinitions の下に WindowsExplorer.adml というファイルがあります。C:\Windows\PolicyDefinitions が本体で、さらに ..\ja-JP\ に翻訳した内容が記述されています。
C:\Windows\PolicyDefinitions\ja-JP>dir WindowsExplorer.adml
ドライブ C のボリューム ラベルは WindowsC です
ボリューム シリアル番号は 1856-98D7 です
C:\Windows\PolicyDefinitions\ja-JP のディレクトリ
2016/07/17 07:15 80,922 WindowsExplorer.adml
1 個のファイル 80,922 バイト
0 個のディレクトリ 25,201,598,464 バイトの空き領域
C:\Windows\PolicyDefinitions\ja-JP>
翻訳はメモ帳で開くとこんな設定が書かれています。gpedit に出てくる内容そのまんまですね。
: 略
<policyDefinitionResources xmlns:xsd="http://www.w3.org/2001/XMLSchema"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; revision="1.0" schemaVersion="1.0" xmlns="http://schemas.microsoft.com/GroupPolicy/2006/07/PolicyDefinitions">;
<displayName>表示名をここに入力する</displayName>
<description>説明をここに入力する</description>
<resources>
<stringTable>
<string id="ABCDOnly">A、B、C および D ドライブのみを制限する</string>
<string id="ABConly">A、B および C ドライブのみを制限する</string>
<string id="ABOnly">A および B ドライブのみを制限する</string>
<string id="ALLDrives">すべてのドライブを制限する</string>
<string id="ClassicShell">クラシック表示のシェルをオンにする</string>
<string id="ClassicShell_Help">この設定を使用すると、管理者は特定の Windows シェルの動作をクラシック表示のシェルの動作に戻すことができます。
: 略
実体を開くと
C:\Windows\PolicyDefinitions>dir WindowsExplorer.admx
ドライブ C のボリューム ラベルは WindowsC です
ボリューム シリアル番号は 1856-98D7 です
C:\Windows\PolicyDefinitions のディレクトリ
2016/07/17 07:20 41,886 WindowsExplorer.admx
1 個のファイル 41,886 バイト
0 個のディレクトリ 25,188,646,912 バイトの空き領域
C:\Windows\PolicyDefinitions>
例えば翻訳では 「AB のみを制限する」内容がこのように記述されています。翻訳版の ja-JP の "string id=" の部分を "item displayName=" で定義しています。
: 略
<item displayName="$(string.ABOnly)">
<value>
<decimal value="3" />
</value>
</item>
: 略
ここで問題となるのが "decimal valu=" の部分です。
- 不可視ドライブの値を決定する -
ここで Decimal Value は Z～A をビットに見立てて、0 は見せるドライブ、1 は見せないドライブです。
Dex:3 は 0011b: 0x03 ですから "D:C:B:A: ドライブの B: と A: はビットが立って、制限して見せない"という事になります。
右からZ:Y:X: .... C:B:A: とビットで制限して、内容を１０進数で表記しているわけです。実に面倒くさい。
例えば D:E:F:P:S: ドライブだけ見せて、他のドライブをエクスプローラーに表示させたくない場合、次の様なバイナリデータが、7桁の十六進数 0x3FB7FC7 となり、 Decimal 十進数では 66812895 となります。
Novell の ZENworks の Knowledge Database に記事があります。
How to restrict drives on workstations
つまり、D:E:F:P:S だけ見せたいという計算はこういう事です。
**ZW|XWVU|TSRQ|PONM|LKJI|HGFE|DCBA <<-- Drive Letter0011|1111|1011|0111|1111|1100|0111 <<-- Binary 1:Hide, 0:Show0x03|0x0F|0x0B|0x07|0x0F|0x0C|0x07 <<-- Hex66812895 <<-- Decimal
という事で、ドライブの見せ方を決定するには面倒で使えない Windows10 の「電卓アプリ」を使って、二進、十進の計算するわけです。
しかし電卓アプリよりこの面倒な数値を求めるサイトが、まだあるのでご紹介しておきます。とても便利です。
不要なデフォルトの Show Only を Delete して、表示したいドライブレターをチェックします。"New" ボタンを押すと、必要最低限の情報だけを作ってくれます。
Export すると、この様な hidedrive.adm が作成されてダウンロードできるので、参考にすると良いでしょう。 D:E:F:P:S: を表示する値は 66813895 になりました。0 は全部ビットが落ちて "ShowAll" で 67108863 は全部にビットが立って "HideAll" になります。
: 略
CATEGORY !!WindowsComponents
CATEGORY !!WindowsExplorer
KEYNAME "Software\Microsoft\Windows\CurrentVersion\Policies\Explorer"
POLICY !!NoDrives
EXPLAIN !!NoDrives_Help
PART !!NoDrivesDropdown DROPDOWNLIST NOSORT REQUIRED
VALUENAME "NoDrives"
ITEMLIST
NAME !!ShowAll VALUE NUMERIC 0
NAME !!HideAll VALUE NUMERIC 67108863 DEFAULT
NAME !!DEFPS VALUE NUMERIC 66813895
END ITEMLIST
END PART
END POLICY
POLICY !!NoViewOnDrive
EXPLAIN !!NoViewOnDrive_Help
PART !!NoViewOnDriveDropdown DROPDOWNLIST NOSORT REQUIRED
VALUENAME "NoViewOnDrive"
ITEMLIST
NAME !!ShowAll VALUE NUMERIC 0
NAME !!HideAll VALUE NUMERIC 67108863 DEFAULT
NAME !!DEFPS VALUE NUMERIC 66813895
END ITEMLIST
END PART
END POLICY
END CATEGORY ; WindowsExplorer
END CATEGORY ;; WindowsComponents
: 略
- 実装してみる -
メモ帳などのテキストエディタで、 C:\Windows\PolycyDefinitions の中身を書き換えて追加する隠しドライブのポリシーを追加します。上書きできないのでいったん保存して、ファイルのバックアップを取ってから、ファイルを PolicyDefinicions にコピーして実装します。
C:\Windows\PolicyDefinitions>type WindowsExplorer.admx
: 略
<item displayName="$(string.DEFPSonly)">
<value>
<decimal value="66813895" />
</value>
</item>
: 略
※C:\Windows\PolicyDefinitions\WindowsExplorer.admx は所有者が Administrator でなければ上書きできません。ファイルのセキュリティの詳細から所有者を Administrator グループなどに変更する必要があります。一応バックアップをとってから書き換えることができました。
C:\Windows\PolicyDefinitions\ja-JP>type WindowsExplorer.adml
: 略
<stringTable>
<string id="ABCDOnly">A、B、C および D ドライブのみを制限する</string>
<string id="ABConly">A、B および C ドライブのみを制限する</string>
<string id="ABOnly">A および B ドライブのみを制限する</string>
<string id="ALLDrives">すべてのドライブを制限する</string>
<string id="DEFPSonly">DEFPSのみ見せる</string>
<string id="ClassicShell">クラシック表示のシェルをオンにする</string>
<string id="ClassicShell_Help">この設定を使用すると、管理者は特定の Windows シェルの動作をクラシック表示のシェルの動作に戻すことができます。
: 略
この様な感じで、追加したポリシーを書き換えて保存します。
※ このC:\Windows\PolicyDefinitions\ja-JP\WindowsExplorer.adml ファイルはいったん別なディレクトリに保管して管理者として上書きします。
実装前
G: I: が見えています。
"DEFPS のみ見せる"が出てきました。「有効」にポリシーを設定して「適用」します。
グループポリシーを即座に適用します。
C:\WINDOWS\system32>gpupdate.exe
ポリシーを最新の情報に更新しています...
コンピューター ポリシーの更新が正常に完了しました。
ユーザー ポリシーの更新が正常に完了しました。
C:\WINDOWS\system32>
エクスプローラからC: H: I: ドライブが消えました。
S:にネットワークの共有記憶領域を割り当てます。S:は見えるようです。
--
今回は、単体PCで実施しましたが、 ZENworks Configuration Management では、変更したPCで iManager から設定し、サーバーにアップすれば良いかと思います。 Windows ドメインを使う場合は、たぶんどこぞの隠し共有フォルダにこのファイルがあるので、書き換えて管理できるでしょう。
このグループポリシーのテンプレート自体をカスタマイズする方法は、若干面倒ですが、他で紹介されているように直接レジストリを書き換える方法より安全でしょうし、また、他にいくつかの Hide Drive Policy のテンプレートを追加して作っておけば応用が利きます。
ドメインコントローラや ZENworks ユーザによって、管理者、ヘルプデスク、一般パワーユーザ、一般ユーザ、先生、生徒の様に様々なパターンが二つのファイルのカスタマイズだけでできるのでとても便利です。
-Keyword-
Windows, Windows10 特定のドライブ, ドライブが見えない, ドライブを不可視, ドライブを隠す, 特定のドライブを非表示, グループポリシー, How to Hide Drive letter from Explorer,特定のドライブを「コンピューター」や「エクスプローラー」で非表示, 指定したドライブを [マイ コンピューター] 内で非表示にする, カスタマイズ, マイコンピュータから特定ドライブを見せない, マイコンピューターからドライブを消す方法,
▲
by islandcenter
| 2017-10-19 11:14
| ZENworks
|
Trackback
|
Comments(0)
2017年 10月 03日
SUSE Linuxと Windows のシャットダウン、リブート操作（仮想サーバーのメンテナンス）
ここでは Linux, Windows のシャットダウン、リブートの方法について説明します。
1) .Linux のシステムを停止、電源遮断する
Linux システムのシャットダウン、再起動コマンドは shutdown コマンドを
実行します。
- 参考ページ -
シャットダウンして、電源遮断(Halt)をするには
# shutdown -h 0 または
# shutdown -h now
シャットダウンして、再起動(Reboot)をするには
# shutdown -r 0 または
# shutdown -r now
-h は halt, -r はリブートの意味です。0 は「０分後」つまり今すぐの意味です。
SLES11の場合
SLES11sp4:~ # shutdown --help
shutdown: invalid option -- '-'
Usage: shutdown [-akrhHPfnc] [-t secs] time [warning message]
-a: use /etc/shutdown.allow
-k: don't really shutdown, only warn.
-r: reboot after shutdown.
-h: halt after shutdown.
-P: halt action is to turn off power.
-H: halt action is to just halt.
-f: do a 'fast' reboot (skip fsck).
-F: Force fsck on reboot.
-n: do not go through "init" but go down real fast.
-c: cancel a running shutdown.
-t secs: delay between warning and kill signal.
** the "time" argument is mandatory! (try "now") **
SLES12 の場合
sles12sp3:~ # shutdown --help
shutdown [OPTIONS...] [TIME] [WALL...]
Shut down the system.
--help Show this help
-H --halt Halt the machine
-P --poweroff Power-off the machine
-r --reboot Reboot the machine
-h Equivalent to --poweroff, overridden by --halt
-k Don't halt/power-off/reboot, just send warnings
--no-wall Don't send wall message before halt/power-off/reboot
-c Cancel a pending shutdown
sles12sp3:~ #
2). Windows のシステムを停止、電源遮断する（特にリモートデスクトップ）
通常にスタートボタン（田ボタン）からシャットダウン、リブートします。
Windows Server 系ならリモートデスクトップでも「田ボタン」から、シャットダウン、再起動のメニューが使えますが、Windowsクライアント系(VDIデスクトップ)の場合、リモートデスクトップから、再起動のメニューが出ません。
もしWindows のリモートデスクトップを使ってシャットダウンする場合はDOS プロンプトを開いて
> shutdown /s /t 0 (シャットダウン)
> shutdown /r /t 0 (再起動)
か、
必ずフルスクリーンモードで alt+f4 キーでシャットダウンのダイアログが出ます。
こちらをご参考ください。
Windows2008 系を KVM/XEN で仮想化している場合、「シャットダウンしています...」が６０秒以上かかる場合、あるいは、シャットダウンし切れない場合があります。
動きがない場合 virt-manager & から Force Off しても構いません。
あるいはコマンドラインで
# virsh(あるいは xm or xl ) destroy my-vmachine-Name_or_vmID_num
で強制終了させます。
3).仮想化ハイパーバイザホストで fsck する場合がある。
なお、長期連続運用後、再起動させた場合、fsck プロセスが走る場合があります。
これは長期間 fsck をしていない場合に必ず行う checkdisk の様な物なので、進捗具合を見ながら放置してください。
数分から数十分かかる場合がありますので、慌てて電源を切らない事です。
OS起動時のfsckのチェック間隔 (※SLES11の場合)
Superblock があるパーティションで
sles11sp4:~ # tune2fs -l /dev/sda9 | grep interval
Check interval: 15552000 (6 months)
sles11sp4:~ #
sles11sp4:~ # tune2fs -l /dev/sda8 | grep -i mount
Last mounted on: <not available>
Default mount options: (none)
Last mount time: Fri Sep 29 13:39:19 2017
Mount count: 44
Maximum mount count: -1
デフォルトでは６か月以上 fsck をしない ext3 パーティションは強制的に fsck されるようです。マウント回数は -1 なので無限大の様です。強制的に fsck させない場合は shutdown コマンドで
-f: do a 'fast' reboot (skip fsck).
オプションを使います。
※ このケースは SLES11 の ext3 フォーマットでのデフォルトです。SLES12 では BtrFS と XFS をデフォルト使用しませんのでこの限りにあらずです。
計画停電時の対策 SUSE (SLES11, SLES12,15) XEN/KVM 遮断マニュアル
SUSE SLES11, ハイパーバイザーのメンテナンス、Linux, Windows, シャットダウン、再起動
▲
by islandcenter
| 2017-10-03 14:00
| SUSE
|
Trackback
|
Comments(0)
2017年 07月 19日
OES Linux ファイルサーバーのファイルアクセス権限の付け替え
- 目的 -
全社、あるいは多くの部署で読み書き可能だったファイルサーバーのフォルダのアクセス権を特定の部署、あるいはグループに特定できるように変更したい。
- OES Linux での操作 -
次の OES ファイルサーバーのフォルダ VOL:test には O=ACE(組織全部)と Yoiko.Uses.Osaka.Ace(グループ)に権限が与えられています。
既に O=ACE に [ RWCEFM ] の権限が与えられているため、全社 O=ACE がこのファイルサーバーのフォルダを読み書きできる状態です。グループオブジェクト Yoiko.Osaka.Ace にもトラスティが与えられていますが、この権限はこの場合は余分です。
したがって、OES ファイルサーバーの VOL:test には グループに関係なくすべてのユーザに権限が与えられています。
これを Users.Tokyo.ACE の OU にのみ解放したい場合 ....
いったんすべてのファイルサーバーの権限を削除して、
特定の部門、グループにだけ権限を与えます。ここでは Users.Tokyo.Ace に権限が与えられ、Osaka.Ace には与えられていません。全社からではなく、一部の部署がファイルサーバーの特定のフォルダにアクセスできるようになります。
※ただし、ログインスクリプトで map f:=VOL: などの記述があると、全くボリュームに権限がないと、マップエラーになります。本来であれば、権限がない時点で map のスクリプトを削除するのがベストですが、何か理由があって、ログインスクリプトに手を加えたくない場合は、dummy ファイルを置いて、[ F ] 権だけを与えたファイルを作っておくと良いでしょう。
試しに VOL:dummy.txt のユーザに [ F ] 権のみ与えてみると、東京では見えるフォルダは見えませんし、F権のみなのでフォルダを見ることはできても中身を確認することができません。
Windows のファイル共有と違って、OES のファイルサーバーのアクセス権(トラスティ)の割り当ては、一か所変えるだけで、メタファイルを一か所変えるだけなので、一瞬で終わります。フォルダの中にどれほどサブフォルダやファイルがあっても、ディレクトリとファイル全体の権限をスキャンして変更しませんので、ファイルサーバーの負荷はほとんど０％です。Windows ファイルサーバーでは数分から数時間かかり、ほとんどその間は、ファイルサーバが利用できない激重状態になります。
次のデモビデオでは、数万ファイルの大量のデータのアクセス権を変える操作を Novell OESでは一瞬、 Windows ファイルサーバーでは３０分以上かかり、その間、ほとんどサーバーが使えなくなっている様子を比較したビデオクリップです。
Novell versus Microsoft: Granting Access Rights
また、権限のない不可視のフォルダ共有はエクスプローラにも表示されないため、共有サーバー上に数百、数千の読み書き不可の共有ディレクトリがあっても、ファイルサーバーが返すディレクトリ情報のポケットは「権限のある」ディレクトリだけなので、ネットワークの負荷が少なく高速に表示されます。
- keyword -
ファイルサーバー アクセス権限 変更 共有フォルダを見せない フォルダのアクセス権限を変える 遅い 重い ファイルサーバーの負荷１００％
▲
by islandcenter
| 2017-07-19 11:23
| OES Linux
|
Trackback
|
Comments(0)
2017年 07月 10日
Wannacry の根本的な対策って？ samba にアクセスできないぞ
すっかり落ち着いてしまったようですが、世間が wannacry ランサムウェアで大騒ぎしていた頃、気になる記事を Gigazine に見つけました。
Gigazine
Windows XPでランサムウェア「WannaCry」の被害が少なかった一因は「ブルースクリーン・オブ・デス」
"WannaCryは「MS17-010」で報告されている、Microsoft Windows SMB サーバーというWindowsのファイル共有システムの脆弱性を利用して広がりましたが"
Gigazine のこの記事によると、 wannacry については Windows XP に感染する前にブルースクリーンになり拡散に失敗するケースが多く、 Windows10 では比較的被害が少ないし、Windows8x 系はそもそもサンプルが少ないので、実際に感染したコンピューターは Windows7 の SMB なんだろうなぁ、という事がぼんやりと気になっていました。
そこで SMB のバージョンについて調べてみました。まぁまぁ良く整理されている記事がこちら。
第7回 ファイル共有プロトコルSMBの概要
そこで wannacry に関する情報を探ると出てくる出てくる。Windows サーバーから、おなじみの samba も影響があるのですね。
- 一番初めに試した対策 -
ほとんどどこでも言及している「SMB 1.0/CIFS のファイル共有のサポート」 デフォルト・イネーブルを削除してみました。
ランサムウェア WannaCrypt 攻撃に関するお客様ガイダンス
「コントロールパネル」＞「プログラムと機能」＞ 「Windows の機能の有効化または無効化」から "SMB 1.0/CIFS ファイル共有のサポート"のチェックを外します。後は「再起動しろ」と言ってくるので、再起動します。すごく再起動に時間がかかります。
再起動すると見事に samba サーバーが「ネットワーク」から消えました。\\IP\Share_name でアクセスもできません。
全滅
です。
という事でこいつ(SMB1.0/CIFS .....)は元にもどす事になりました。つまりはこれも拡散を防ぐための一時的な対策に過ぎません。
- samba サーバー側で対応してみる -
==========
Workaround
==========
Add the parameter:
nt pipe support = no
to the [global] section of your smb.conf and restart smbd. This
prevents clients from accessing any named pipe endpoints. Note this
can disable some expected functionality for Windows clients.
という事だそうです。
smb.conf — Samba の設定ファイル
によると
nt pipe support (G)
この真偽値パラメーターにより、 smbd(8) が Windows NT のクライアントに対して、 Windows NT の SMB 固有の IPC$ パイプへの接続を許可するかどうかが制御される。 これは開発者のデバッグオプションであり、意識する必要はない。
既定値: nt pipe support = yes
”意識する必要はない ”とはありますので、とりあえず 手元の SUSE Linux SLES11 で設定してみます。
yast(or yast2) > Network Service > Samba の Identity タブの Advanced Setting からこの Expert Global Settings を書き換えます。
Add ボタンで "nt pipe support" にチェック（デフォルト）が入っているので、このチェックを外すと smb.conf が書き換えられます。この状態で yast でOKすると samba が再起動します。
ところが
見事にアクセスが拒否られます。また Windows7 とサンドボックスの Windows XP も見事アクセスが拒否されました。
つまり
nt pipe support = no
パラメータはあくまでも一時的なものであり、根本解決には至りません。
という事で SUSE から出ているパッチを探してみました。これの様です。
- SUSE のパッチ -
CVE-2017-7494
結構メンド臭そう。やっぱり公式リポジトリからセキュリティ系のアップデートを全部パッチするのが正解の様です。
怖いのは、Linux のディストリビューション各社はパッチをだしているのですが、よく国道沿いのディスカウントショップで「家族計画用品」の隣で売られているご家庭製品専門のメーカーで出しているような、「なんちゃって我が家のNAS」みたいなものがパッチを出していなかったり、当てるのも面倒だったり、そもそも wannacry に対策しているかどうかもわからないところですね。
ということで
第一段階
SMB1.1/CIFS の利用をやめて Samba や NAS の使用を停止して、エンドユーザに総スカンを食らう
その間にパッチを全部確認する。
第二段階
手に入る限りの Windows パッチ、Samba パッチを当てまくり、リブートしまくり、ついでにあちこちでトラブルが出て、みんなに総スカンを食らう。
第三段階
PCを「安全性が高い」とマイクロソフトが豪語する Windows10 と Windows 2016 Server にリプレースして、SMB3.11 にアップデートして samba も 4.x にアップデートして SMB3.x のみサポートして、動かないアプリケーション続出しまくり、繋がらない古いPCユーザから総スカンを食らい、金をかけた効果はあったのかと経営者に詰問されて、辞表を書く。
というのが対策の手順となりそうです。
- Keyword-
wannacry, 対策, Windows10, Windows7, samba, SMB, CIFS, Linux, 脆弱性
▲
by islandcenter
| 2017-07-10 18:08
| プライベートクラウド
|
Trackback
|
Comments(0)
2016年 10月 17日
WSUS のディスク容量がピンチ！空き容量を一挙に増やすには
この記事は書き換える可能性があります。
2016/10 より、Windows Update のポリシーが変わったせいでしょうか、急に WSUS の容量が爆発的にふえてしまったのです。
1) インストール済のパッチの拒否
2) クリーンアップウィザード
3) WSUS 自身のアップデート
4) 同期
5) 世間のパッチの不具合の話題をチェックしてインストールの承認
6) パッチのダウンロードと配信
という流れが出来てきます。これで毎月運用していれば WSUS の使用ディスク容量なんて２０Gから３０G程度で落ち着いてくれます。
ところが、ある日、クリーンアップウィザードを実施しても、全然キャッシュが消えないという不思議な現象に出くわしました。WSUS ピンチです。40G確保したD:ドライブを dd コマンドで４Gほど増やしてみて（当然仮想化運用です）も、キャッシュドライブは、大泉洋が作るスパゲッティみたいに膨れ上がる一方です。
ということで、WSUS の空き容量を緊急に確保する緊急手段です。
Windows Update Service > 「オプション」 > 「更新ファイルと更新言語」を開きます。
ギリギリだった容量が一挙に回復しました。
OES 2018 Linux で SMB ファイルサーバーのフォルダ容量制限(ディレクトリクォータ) https://islandcnt.exblog.jp/238412872/ フォルダの容量制限付きアーカイブ専用ファイルサーバー：サーバーをゴミ箱にしない工夫 https://islandcnt.exblog.jp/238371771/ クライアントPCのBCP対策 D:ドライブにドキュメントを保管・バックアップ https://islandcnt.exblog.jp/238911684/
▲
by islandcenter
| 2016-10-17 17:20
| プライベートクラウド
|
Trackback
|
Comments(0)
2016年 07月 12日
Windows10のゲストユーザが Microsoft ID なしでストアアプリを使う
関連記事
Windows10 HOME でパスワードがないゲストユーザを作る
Windows10 Microsoft アカウント<-->ローカルアカウントの変更
の続きです。
Windows10 に作成した、「ゲストユーザ」にストアアプリを使ってもらう事を想定してみましょう。例えば貴方のタブレットをちょっとの間、パスワードのないゲストアカウントで知人に貸し出したり、リモートデスクトップでＶＤＩサーバーしか使わない、格安シンクライアントにログインした、パスワードなしのユーザ、（ＶＤＩは Windows7 だったりするので、ストアアプリは使えない）にストアアプリにある、ニュースアプリや天気予報、乗り換え案内など、業務や、ちょっとした行動に必要なブラウザでは使えないアプリをインストールしておくことがあります。あるいは、"MyHomeUser" など、パスワードを必要としない我が家のガキンチョどもに、ちょっと使わせたい、なんてシーンはゴロゴロしているわけですね。そんな目的で、Microsoft アカウントと紐づけされていないＰＣに、ストアアプリをインストールする方法をチェックしてみました。
前提条件として、このユーザはパスワードもなくサインインできて、Microsoft ID とは紐づけされていないユーザです。
- ストアアプリにサインインしてアプリをインストール -
ストアアプリを起動して、「検索」窓左の人型アイコンをプルダウンして、「サインイン」します。
アカウントの選択で "Microsoft アカウント"を選びます。
ここで既にある Microsoft アカウントでサインインします。
Microsoft ID のユーザ名とパスワードをセットして
"このアプリのみサインイン"します。
これで Windows ストアにアクセスできるので、天気予報アプリを使ってみました。
問題なく使えるようです。
- サインアウトする -
ストアアプリからサインアウトするには、検索ボックスの人型アイコンからサインインしたアカウントをクリックして”サインアウト”します。
無事サインアウトしたようです。
.png)
この状態であれば、天気予報やニュースアプリのように Microsoft アカウントを使わないストアアプリであれば、問題なく利用できるようです。ちなみに、一つの Microsoft アカウントで同時に利用できるデバイスは１０台までとの事ですが ....[Windows 10]ストアアプリのインストール回数はどのように管理するのでしょうか?
「設定」＞「アカウント」＞「お使いのアカウント」＞「Microsoft のアカウントの管理」でブラウザが起動します。 Windows Live へログインし、「デバイス」メニューから「ＰＣの削除」が行えます。
これで、Microsoft アカウントとデバイスとの紐づけを解除したら、１０台以上に”天気予報アプリ”がインストールできるか、どうなのか。残念ながらそんなにＰＣ持っていないので試していませんが、やっぱりデバイス情報には、インストールされたＰＣがリストされたので、１０台以上のＰＣに一つのアカウントでインストールはできないようです。
10台以上デバイスをお持ちの方のフォローがあったら嬉しいです。
-Keyword-
Microsoft Windows ID Windows10ＩＤなし ストアアプリのインストール ゲストユーザ アカウントの紐づけがない アカウントの紐づけされていない Windows ID パスワードなしのユーザ 激安 格安 シンクライアント Windowsアプリ 使いたい。
▲
by islandcenter
| 2016-07-12 11:55
| Windows
|
Trackback
|
Comments(0)
2016年 06月 24日
リモートデスクトップからWindows10 を簡単に再起動する方法
Windows10 で ＶＤＩ（仮想デスクトップ）を導入すると、何しろ周辺機器がつながっていないので、まず、再起動しなければならないケースは少ないとは思いますが、「どうしても再起動したいんだよ」というケースがたまにあります。
しかし、リモートデスクトップでＶＤＩシステムに接続している場合、「電源」ボタンにはセッションの「切断」かユーザ名アイコンから「サインアウト」しか選べません。
そこで MSTSC.exe (リモートデスクトップ)で、接続中の、ＶＤＩシステムの Windows10 をリモートで再起動する方法を考えました。
- ＡＬＴ＋Ｆ４キーを押す -
一番お手軽なのがこの方法ですが、ALT+F4キーは「アプリケーションの終了」でもあるため、デスクトップを「全画面」にして操作しなければなりません。
また、この方法では誤って「シャットダウン」を選択してしまう場合があります。シンクライアントシステムで、「シャットダウン」を実行すると、ご本尊まで行って電源投入を手動で行う必要があって、あまり塩梅が良くありません。ＶＤＩシステムの場合は、仮想クライアントの起動をシステム管理者が行う必要があるため、この方法はあまりお勧めできないわけです。
- コマンドラインから shutdown -r -t 0 /r /f /t 0 を実行する -
※ 初出で"-r" と書いてしまいました。これは UNIX 系ＯＳの場合ですね。DOS 系は "/r" でした。
という事で、シャットダウンをバッチ処理する方法がお勧めです。
次のようなバッチファイルを作成して \Windows\system32 あたりに reboot.bat という名前で作成します。メモ帳では直接保存できないので、いったんテンポラリに作成して、強引にコピーしてしまいます。
=====================ここから======================
echo off
echo .
echo .
echo .
echo .
echo =========== リブートします。~C で中止 ===========
echo .
echo .
echo 何かキーを押すとリブートします。
echo .
pause
cls
shutdown /r /f /t 0
exit
========================ここまで===================
その他の shutdown.exe のパラメータはヘルプで参照してみてください。ここで使っているのは
/r : リブート
/f : アプリケーションの強制終了
/t 0 : 0 秒後にウエイトなしでリブート
です。ちなみに /s を付けるとシャットダウンですので、リモートの「ご本尊」の起動操作が必要になってしまいます。管理者が何らかの理由で停止/メンテナンスが必要な場合にのみ使う事になるでしょう。後は、このバッチファイルをデスクトップだとかタスクバーに登録しておけば、実にあっさりと再起動してくれます。
ここでは pause で止めて "CTRL+C" でキャンセルできるようにしていますが choice.exe なんかを組み合わせるともっとナイスなバッチファイルが出来上がります。
Windows10 リモートデスクトップ 簡単に再起動したい シャットダウンしたい ＶＤＩシステム 仮想化クライアントの再起動 バッチファイル
▲
by islandcenter
| 2016-06-24 11:51
| プライベートクラウド
|
Trackback
|
Comments(0)
2016年 04月 11日
Hyper-V の仮想化でメモリリークがあり、異常に遅くなる。
- 現象 -
Hyper-V が動作すコンピュータのメモリ利用状態が９０％を超えた状態で、全てのレスポンスが異常に遅い。すべてのアプリケーションを終了させたが、メモリ利用状況は変わらず 90% を超えている。
.png)
なんじゃこれ！
- 内容 -
やむを得ずシステム全体を再起動したが、状況は２日程度で再現する。
Hyper-V で仮想マシンが動いていたのでシャットダウンしたら現象が回避できた。
.png)
なんじゃこれ！
- 原因 -
Hyper-V で仮想マシンをシャットダウンしたら修復できた。 Windows + Hyper-V のメモリリークと思われる。ちなみに動作していた仮想マシンは 768Mb のメモリしか占有していなかったにも関わらず6G以上のメモリがリークされ、ガーベジコレクションも行われない。ちなみに同じ仮想システムイメージは他のハイパーバイザーでは再現しない。
- 対策 -
- Hyper-V ハイパーバイザーを定期的にリブートする
- 仮想コンピューターを定期的に夜中にリブートする。
- Hyper-V から別なハイパーバイザーに乗り換える。
なお、仮想コンピューターをシャットダウン、リブートするコマンドラインはないので、VBscript などを書くか GUIから手動で行わなければならない。夜中の業務時間外にリブートするコマンドは標準では実装できないので、深夜出勤してGUIで操作するか、 Hyper-V 自体のハードウェアを UPS や Shutdown コマンドで定期的に業務時間外にリブートする方法が最適と考えられる。
だから、 Hyper-V だけは絶対やめた方がいいと言っただろうが。
関連記事
▲
by islandcenter
| 2016-04-11 06:41
| Windows
|
Trackback
|
Comments(5)
2016年 04月 01日
Administrator 以外のドメイン一般ユーザがリモートデスクトップに接続できない。
Administrator 以外の一般ユーザがリモートデスクトップＰＣクライアントを利用できない。
- 現象 -
ドメインに参加しているＰＣに対して Administrator@mydomain.intra ユーザがログオンすることができるが、一般ユーザ user@mydomain.intra がログインできない。MSTSC からログインしようとすると
「このリモートコンピューターにログオンするには"ターミナルサービスを使ったログオンを許可する" 権利が必要です.....」
と表示されログインできない。なお、このユーザは "Remote Desktop Users" グループに所属させている。
- 対策 -
リモートデスクトップＰＣに接続するユーザを「対象のＰＣ」にリモートデスクトップ接続できる様にリストに追加する必要がある。
具体的には、Administrator@mydomain.intra でログインしてから、コンピューター > 右ボタン「プロパティ」 > リモートデスクトップ接続、の中の「ユーザの選択」の中に「追加」ボタンから、リモートデスクトップ接続を許可するドメインユーザ（もしくは別途作成したユーザグループにユーザを追加し）を検索して「追加」する必要がある。
ちなみに、このグループに Built in Group である"Remote Desktop Users" はリストに出ないため選べない。（すごい仕様だ）
この作業を行わないと、ドメインユーザがＶＤＩなどのサーバーにインストールされた仮想ＰＣのリモートデスクトップが利用できない。
ちなみに、この問題のユーザを ドメインの中で "Remote Desktop Group" から削除しても、ローカルＰＣにリモートデスクトップユーザ、あるいはユーザグループとして登録しておけば、問題なく接続できる。(つまりＤＣで Remote Desktop User を設定しても無意味なんだな、何のためのＤＣなのよ...とほほ)ＤＣサーバー側からの制御はできない。
本当か .....? ってかこの方法しかなかったンだけど、他にいいアイディアがある方はコメントください。
ちなみにユーザかグループは選べるが、コンテナ(OU) は選択できない非常におバカな仕様である。当たり前だが Novell eDirectory よりバカだな、やっぱり Windows って。
ファイルサーバーのフォルダ容量制限(ディレクトリクォータ)
▲
by islandcenter
| 2016-04-01 11:13
| Windows
|
Trackback
|
Comments(0)
