無法使用以DNS建立的CNAME紀錄，連接SMB檔案分享

前陣子利用Windows 2012建立了一個File Server來作擋案分享，不過依循系統管理原則命名的伺服器名稱，在管理上容易分辨與管理，但是可能與使用者的記憶習慣可能會有所不同

為了在管理者與使用者兩者之間取得平衡，可能會選擇採用DNS建立一筆CNAME紀錄這樣的方式，但是實際使用時，就會發現UNC路徑連接到\\CNAME時，可能會發生驗證失敗或是一片空白的狀況


參考微軟文件後，解決方式可分為單機與叢集資源....
微軟文件：https://support.microsoft.com/en-us/help/3181029/smb-file-server-share-access-is-unsuccessful-through-dns-cname-alias

如果是單機的話，可透過以下方式：

1. 透過修改機碼的方式關閉名稱檢查

Registry location:
  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
DWORD name:   DisableStrictNameChecking
DWORD value:  1

2. 透過指令將伺服器帳戶新增到網域 (文件中有特別提醒「不建議使用，除非您堅持」)

NETDOM COMPUTERNAME /ADD


3. 設定SPN(service principal names)

SETSPN -a host/alias_name targetserver
SETSPN -a host/alias_name.contoso.com targetserver

SMB檔案分享是在Windows 2012並且有叢集化，可以透過「設定Alias別名」的方式

參考文件：https://blogs.msdn.microsoft.com/clustering/2012/04/08/how-to-configure-an-alias-for-a-clustered-smb-share-with-windows-server-2012/

1. 先透過以下指令，確定叢集資源中，是否有指定別名 (通常是空白)
Get-ClusterResource "MyClusterName" | Get-ClusterParameter Aliases
2. 再使用以下指令，指定別名 (通常是空白)
Get-ClusterResource "MyClusterName" | Set-ClusterParameter Aliases Alias別名
3. 最後重覆第一個指令，確定別名是否有指定成功 (通常是空白)
Get-ClusterResource "MyClusterName" | Get-ClusterParameter Aliases
4. 如果Alias別名的設定確認無誤，請讓叢集資源離線後再重新上線

注意事項：

文件中有提到，如果是以IP、Alias別名來連接至SMB檔案分享，這些連線是不支援Kerberos驗證的，連線驗證會使用傳統的NTLM，使用Alias別名雖然帶來了便利性，但是要考慮一下安全性

如果需要設定多個別名，請以雙引號"框起所有Alias別名，每個別名中以逗號,分隔，請參閱下面範例：

Get-ClusterResource "MyClusterName" | Set-ClusterParameter Aliases "Alias別名1,Alias別名2"

SuSE Linux vim 變更註解顏色

SLES透過putty連入時，使用vi打開設定檔時，那個深藍色的註解，讓人會看到眼睛瞎掉啊 (見下圖)

如果能改成這樣，不是會比較好嗎？

網路上有很多修改方式，不過因為我使用的是SuSE Linux Enterprise Server，覺得SuSE對Linux的整合作業作的很不錯，像它的yast、SuSEconfig、Apache的設定整理方式 ...等 (用過的人應該會知道我說的是什麼)，所以個人不想做太多的異動 ，以免破壞SuSE的設計。

所以我選擇做最小幅度的調整，在SLES 12請修改以下這個檔案：

/usr/share/vim/vim74/syntax/syncolor.vim

找到以下這行，在前面加上 " 將其註解掉 (注意：不是用#)

SynColor Comment term=bold cterm=NONE ctermfg=DarkBlue ctermbg=NONE gui=NONE guifg=Blue guibg=NONE

然後，把前一段的複製下來 (要直接改掉紅色粗體字的地方也可以)

SynColor Comment term=bold cterm=NONE ctermfg=Cyan ctermbg=NONE gui=NONE guifg=#80a0ff guibg=NONE

npm使用Proxy

公司使用的TFS Build Agent因應開發者的需求安裝了Nodejs，而Nodejs的npm指令與NuGet一樣，會透過網路下載套件，不意外的，位於封閉網路中的上網問題又再次發生了

由下圖可以看到，畫面上顯示的「ETIMEOUT」就代表連接失敗

上網找了一下，基本上npm可透過指令設定proxy的參數，指令如下：

npm config set proxy http://proxy.server:proxy_port
npm config set https-proxy http://proxy.server:proxy_port

比較特別的地方是，進行 https-proxy 設定時，設定主機的地方依舊是用「http://」，而非「https://」，如果僅依照以往經驗設定成「https://proxy.server:proxy_port」，這是會失敗的，請參考下圖

不過，若您的 npm 是由其他服務、批次作業呼叫，並且以其他獨立的帳號執行，而這個帳號不允許登入 Windows 的話，也可以採用「設定檔」的方式來調整 Proxy 這個部分

設定檔中，只要輸入以下內容後存檔即可：

proxy = http://proxy.server:proxy_port
https-proxy = http://proxy.server:proxy_port

而設定檔的路徑在參考官方文件 (npm config)後，發現設定檔也是有分Project、User、Global、built-in這些等級
至於各種等級的差異，在文件上都有說明，這邊就不再贅述，但是文件上的說明，都是以 Linux   環境為基礎，倒是 Windows   環境中，會不知道檔案放在哪裡，以下為   Windows   環境中的對應 (紅色字體為檔名)

Project：C:\Project\.npmrc
User：C:\Users\<account>\.npmrc
Global：C:\Users\<account>\AppData\Roaming\npm\etc\npmrc
built-in：C:\Program  files\nodejs\node_modules\npm\npmrc

下圖為透過指令 npm config list 所列出的設定路徑，貼上來給大家參考一下

附帶一提，Project、User等級的檔名為.npmrc，在 Windows 檔案總管中，是無法將檔案改為這種檔名，請透過文字指令模式調整：

move C:\Project\npmrc.txt C:\Project\.npmrc

透過指令fsutil，檢視Disk block size

 作業系統使用之磁碟機，在格式化檔案系統時，有時會需要配合應用程式的行為模式，來指定不同的block大小，目前常碰到的就是SQL Server需要配合調整

SQL Server在運行時，對於磁碟的存取通常是8K ~ 64K的IO，在微軟原廠的效能調效說明也建議，SQL Server放置資料檔案的磁碟，應格式化為64K。
※64k僅是一般建議，如果能實際測試會更好

微軟文件：​https://docs.microsoft.com/en-us/previous-versions/sql/sql-server-2008/dd758814(v=sql.100)


格式化時，請確認「配置單位大小」為 64 KB (預設為4096)

 而已建置之系統，可以在「文字指令模式」，透過以下指令，檢視目前的磁碟block size
fsutil fsinfo ntfsinfo c:

如果是4k block，會看到叢集位元組數目為4096

如果是64k block，叢集位元組數目會是65536

NuGet 設定 Proxy - Windows

說明

在企業的程式開發協同作業上，微軟強力推薦Azure雲端的VSTS (Visual Studio Team Services)，但是企業有時會因為法令、政策的考量，部分企業仍會選擇地端的TFS。
目前我所任職的公司使用TFS 2018，但它的 Build Agent 在組建程式的時候會使用NuGet連接網路下載套件。
而位處於封閉網路內的TFS僅能透過Proxy下載套件，因此需要調整NuGet的設定，讓NuGet可透過Proxy進行下載。

調整方式

針對 NuGet 使用 Proxy有三種層級可以設定 (如同 Dot Netframework 一樣)，個人是使用「使用者層級」的設定，設定於 TFS Agent服務之啟動帳號中：
​參考文件：微軟文件庫 - 設定 NuGet 行為

範圍	NuGet.Config 檔案位置	描述
專案 Project	目前的資料夾 (也稱為專案資料夾) 或最高到磁碟機根目錄的任何資料夾。	在專案資料夾中，設定僅適用於該專案。 在包含多個專案子資料夾的父資料夾中，設定適用於這些子資料夾中的所有專案。
使用者 User	Windows：%appdata%\NuGet\NuGet.Config Mac/Linux：~/.config/NuGet/NuGet.Config或~/.nuget/NuGet/NuGet.Config (依 OS 發行版本而異)	設定適用於所有作業，但會覆寫為任何「專案層級」設定。
電腦 Computer	Windows：%ProgramFiles(x86)%\NuGet\Config Mac/Linux：$XDG_DATA_HOME。 如果$XDG_DATA_HOME為 Null 或空白，則會使用~/.local/share或/usr/local/share (依 OS 發行版本而異)	設定適用於電腦上的所有作業，但會覆寫為任何「使用者」或「專案層級」設定。

NuGet.config使用Proxy之設定內容：

<configuration>
  <!-- Proxy設定開始 -->
  <config>
  <add key="http_proxy" value="http://my.proxy.address:port " />
  <add key="https_proxy" value="https://my.proxy.address:port " />
  <add key="no_proxy" value="*.domain1.com,*.domain2.com" />
  <!-- <add key="http_proxy.user" value="myDomain\myUserID" /> -->
  <!-- <add key="http_proxy.password" value="密碼經過base64編碼後之產出字串" /> -->
  </config>
  <!-- Proxy設定結束 -->
</configuration> 

如何遷移Microsoft Dynamic CRM 2013的資料庫

之前發現，CRM系統的資料庫使用率其實很低，每週的CPU平均用量都在5%以下，所以當初廠商的建議的規格實在是有點太高。
為了節省資料庫的授權費用，也讓合適的機器用在適合的地方，所以做了罕見的資料庫「硬體降級」的動作，將DynamicCRM的資料庫從32 core的伺服器，遷移至16 core的伺服器上。

※ 這個動作會讓Dynamic CRM 2013有短暫的時間無法提供服務。

 作業方式參考以下網址：
​https://community.dynamics.com/crm/b/tsgrdcrmblog/archive/2014/08/15/changing-a-microsoft-dynamics-crm-2013-sql-server-for-a-deployment

文中有提到如何遷移DynamicCRM 2013的資料庫到新的主機上，以下簡短節錄內容：
請修改應用程式主機的機碼：

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSCRM\configdb

機碼原始值：

DataSource=Old_SQLServer;InitialCatalog=MSCRM_CONFIG;Integrated Security=SSPI

機碼新值：

DataSource=New_SQLServer;InitialCatalog=MSCRM_CONFIG;Integrated Security=SSPI

移動 CRM 組織資料庫：

1. 在原有的SQL Server上，備份CRM組織資料庫
2. 將前一作業的備份檔，還原至新的SQL Server叢集

在DynamicCRM 2013的「佈署管理員」(Deployment Manager)進行以下程序：

1. 「停用」組織
2. 在組織項目，選擇「編輯組織...」
3. 變更「編輯項目」中，將舊SQL Server的主機名稱為新SQL Server的主機名稱
4. 「啟用」組織 

額外分享
在做遷移的時候意外發現，資料庫AlwaysOn進行failover後，並且將原先32 core的伺服器關機後，Dynamic CRM 2013的服務是會有異常的。這才發現 Dynamic CRM 2013並不支援AlwaysOn，當年廠商的規畫、建置實際上是錯的。

SSIS：伺服器可能資源不足，或者組件具有 PERMISSION_SET = EXTERNAL_ACCESS 或 UNSAFE 而不受信任。

前陣子公司採用AlwaysOn的資料庫增加了新節點，並且將Primary角色切換至新節點執行時，發現當執行SSIS的封裝時會發生以下錯誤：

嘗試載入組件識別碼 65536 時，Microsoft .NET Framework 發生錯誤。伺服器可能資源不足，或者組件具有 PERMISSION_SET = EXTERNAL_ACCESS 或 UNSAFE 而不受信任。
請再次執行查詢，或參閱文件集，以了解如何解決組件信任問題。如需有關此錯誤的詳細資訊:
System.IO.FileLoadException: 
無法載入檔案或組件 'microsoft.sqlserver.integrationservices.server, Version=11.0.0.0, Culture=neutral,PublicKeyToken=89845dcd8080cc91' 或其相依性的其中之一。
發生關於安全性的錯誤。 (發生例外狀況於 HRESULT: 0x8013150A)  
System.IO.FileLoadException:
 於System.Reflection.RuntimeAssembly._nLoad(AssemblyName fileName,String codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)
 於 System.Reflection.RuntimeAssembly.InternalLoadAssemblyName(AssemblyName assemblyRef, Evidence assemblySecurity, RuntimeAssembly reqAssembly, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)
 於 System.Reflection.RuntimeAssembly.InternalLoad(String assemblyString, Evidence assemblySecurity, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean forIntrospection)     
 於 System.Reflection.RuntimeAssembly.InternalLoad(String assemblyString, Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean forIntrospection)
....(略) 

解決方式： 請執行以下語法，變更SSISDB之屬性即可

ALTER DATABASE SSISDB SET TRUSTWORTHY ON;