建立大量的mklink ?

事情是這樣的

由於某些緣故，某個系統資料夾內的空間快面臨不足的情況，爬了一下文似乎可以利用mklink的方式把檔案先暫時搬移到其他地方再建立連結回來。

但是由於要搬移的資料夾數量實在太多，一筆筆去建立連結似乎太傻了點，爬了一下文章，有鄉民提供一個不錯的方式。

情境如下：
把C:\temp下的資料夾移動到d:\temp
自動去掃描d:\temp底下有多少資料夾，自動建立連結回c:\temp
語法範例如下：

for /f "delims==" %%k in ('dir "d:\temp\"  /b') do (
mklink /d "c:\temp\" "%%~k"
)

Reference
How do I create a symbolic link using a batch script in windows?

MKLINK - 因為符號連結的類型已停用，所以無法遵循符號連結。

事情是這樣的

環境：
FILE SERVER1
FILE SERVER2
CLINET SERVER

由於FILE SERVER空間快滿了，而且機器已經無法再擴充空間，於是想到可以透過mklink方式把一些不常用的檔案搬移到FILE SERVER2上。

於是在FILE SERVER1 建立好mklink
# mklink /d D:\XXXX  \\FILE SERVER2\XXXX

正當我興高采烈的時候，透過CLIENT去存取卻發生下列錯誤：

因為符號連結的類型已停用，所以無法遵循符號連結。

後來查了一下，必須要在CLIENT端去開啟遠端至遠端存取的權限。
一開始爬文章沒有注意的我，一直在FILE SERVER那邊測試了老半天。XD

查詢的指令

fsutil behavior query SymlinkEvaluation

開啟遠端至遠端的指令

fsutil behavior set SymlinkEvaluation R2R:1

參考來源：
 windows mklink指示用法
The symbolic link cannot be followed because its type is disabled

WINDOWS 10 2017年10月份更新-造成系統無法開機(KB4041676、KB4041691、KB4000824)

今天一大早陸續收到許多使用者反映電腦無法正常開機。
(李組長眉頭一皺，發現案情並不單純。)
於是看了一下鄉民的討論，才發覺大事不妙

 似乎是透過WSUS伺服器更新"delte"，就會造成系統無法開機

 詳情可以參考
KB4041676 -  https://support.microsoft.com/en-us/help/4041676

KB4041691 – https://support.microsoft.com/en-us/help/4041691

KB4000824 https://support.microsoft.com/en-us/help/4000824

目前解決的方法就是
1.先快速到WSUS伺服器去搜尋delt， 然後先把這幾個更新拒絕核准。
2.逐一到受害的電腦，把安裝的更新移除

移除步驟就是
1.先進入WINRE
2.命令提示字元，透過Dism移除 (詳細參照下方的參考來源)

Dism /Image:C:\ /Get-Packages (could be any drive, had it on D, F, and E.)
Dism /Image:C:\ /Remove-Package /PackageName:package_ for_###

註：主要是移除下列三個，重新開機就可以了

Rollupfix_wrapper~31bf3856ad364e35~amd64~14393.1770.1.6
Rollupfix~31bf3856ad364e35~amd64~14393.1770.1.6
Rollupfix~31bf3856ad364e35~amd64~14393.1715. 1.10

參考來源：
 Windows security updates broke 30 of our machines
The October 2017 Update – “Inaccessible Boot Device”

網路芳鄰無法存取 (可怕的群組原則派送後)

如果你跟我一樣，是在派送過後群組管理原則之後才發生的。
那麼本篇有可能有很高的機率可以給予一些小小的幫助。

==看結果的可以直接跳過==
事情是這樣的........
由於某些原因，必須從AD中派送群組原則
但沒想到派送之後，才是一連串的 惡夢開始 XD

大部分都一一解決，但有一個問題卻是弄了非常久
就是 網芳存取
而且奇妙的是，我把派送的原則停用之後，一樣發生無法存取(即使我重開機)

這就妙了，因為大部分的問題，只要停止原則後都可以恢復正常，再來一一找問題。
但是網芳存取的錯誤卻不是，這讓我產生疑惑，真的跟群組原則有關嗎
畢竟停用之後問題仍然發生，可是這問題是派送之後才發生的
我就一個人像鬼打牆般的在那試了又試
眼看著使用者一直打電話來催促
 心想這樣下去不是辦法 ，於是開始了以下測試

找一台尚未套用原則的電腦
測試透過網芳存取伺服器 => 正常
套用原則
測試 => 失敗

證實果然跟原則有關係

此時把一半的原則手動一個個設定回去
測試網芳存取 => 正常

看起來越來越接近答案
就這樣利用二分法(是這樣說嗎)
終於找到是某項設定照成的
跟我在GOOGLE上看到的解答 不大一樣 XD
==看結果的可以直接跳過==

電腦設定=>Windows設定=>安全性設定=>安全性選項
Microsoft網路用戶端：數位簽章用戶端的通訊(自動)
設定為已停用，然後重新開機

以上提供給有相同困擾的朋友參考看看

驚魂的HYPER-V 虛擬主機系統事件簿

由於電力中斷測試，於是把主機關機。
覆電之後，打開主機之後...........是這一切惡夢的開始。

虛擬主機開啟之後，異常的緩慢，然後就沒有回應。（指的是無法遠端連線，本機的鍵盤滑鼠拔除後再接回去也沒有反應）

接下來就是一直不斷的在完關機開機的遊戲。

時間一分一秒的過去了，這樣下去不是辦法。
於是把所有的網路線都拔除（包含使用iscsi的光纖線）

此時開機之後的主機非常正常，於是把焦點放到網路裝置上。

這時使用二分法測試。
把網路線接上去，光纖線先不接上（光纖是用來連接儲存設備用的）

繼續開關機遊戲，主機都是正常的，最後不信邪的把光纖線接回。
果不然.......主機又異常了。

於是把所有主機都先開起來（不接光纖線），先讓主機的容錯移轉服務正常啟動。

接著把光纖線接上去，檢查isci連線路徑 一一掛載回去。

等儲存裝置上線，在一一把虛擬機器打開。

這才結束了這次的驚魂記。

鬼打牆的您沒有安裝silverlight

最近碰到瀏覽使用silverlight元件網站時，出現安裝Silverlight的訊息



把Silverlight拿出來安裝，結果系統會說已經安裝了。
當下反應就是先把silverlight移除後，重新安裝。（無效）
後來一直反覆的測試才發現是ActiveX篩選稿的鬼，把勾勾移除後就正常了。