Code block

Google Code Prettify + AD Sense

2018年8月17日 星期五

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

注意事項:

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

    如果需要設定多個別名,請以雙引號"框起所有Alias別名,每個別名中以逗號,分隔,請參閱下面範例:
    Get-ClusterResource "MyClusterName" | Set-ClusterParameter Aliases "Alias別名1,Alias別名2"

2018年8月9日 星期四

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


2018年7月26日 星期四

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

2018年7月24日 星期二

透過指令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

2018年7月13日 星期五

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> 

2018年7月12日 星期四

如何遷移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;

修正Surface Pro解析度過高,導致遠端桌面內容過小的方法

參考網頁 https://blog.brankovucinec.com/2016/03/19/fix-remote-desktop-dpi-scaling-issues/

公司前陣子採購了一批行動裝置 Surface Pro 4,讓On call的工程師在外移動時能更加方便,但是Surface Pro 4的螢幕採用品質較高的液晶面板,其解析度達到2736 x 1824,超越一般Notebook、PC螢幕。

因此若工程師在Surface Pro上使用「遠端桌面連線」到伺服器時,如此高的解析度,會讓「遠端桌面連線」中的桌面內容、圖示變得很小、不易辨識,進而造成處理事件、維護作業的困難。 為了解決這個問題,已下列出參考網址中修正問題的程序。

Sufrace Pro之個人心得分享

個人覺得,技術人員出門在外若僅需要遠端連線功能,各家平板iPad、Surface、Android Pad比較起來,還是Surface比較好用,因為它使用Windows作業系統,在軟體安裝上很方便 (例如:VPN Client軟體)

但是Surface Pro也是有一些缺點,以蓄電、省電能力來說,iPad、Android pad可能還是比較好,出門前一定要充電,目前也無法使用行動電源充電。所以針對Surface Pro,個人建議把它看成是一台「非常輕薄的筆記型電腦」會比較適合。

※ 完成修正程序之後,開啟遠端桌面軟體時,請軟體的「顯示」的項目請設定為「全螢幕

修正程序

  1. 調整SurfacePro裝置中Windows 10機碼 (新增)
    1. 新增機碼之位置:HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\SideBySide
    2. 新增之機碼的型態:DWORD (32 bit)
    3. 新增機碼的名稱:PreferExternalManifest
    4. 新增機碼的值:1
  2. 新增檔案至 %SystemRoot%\System32 (預設為C:\Windows\system32)
    1. 新增之檔案名稱:mstsc.exe.manifest
    2. 新增之檔案內容: 
      <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
      
      <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0" xmlns:asmv3="urn:schemas-microsoft-com:asm.v3">
      
      <dependency>
        <dependentAssembly>
          <assemblyIdentity
            type="win32"
            name="Microsoft.Windows.Common-Controls"
            version="6.0.0.0" processorArchitecture="*"
            publicKeyToken="6595b64144ccf1df"
            language="*">
          </assemblyIdentity>
        </dependentAssembly>
      </dependency>
      
      <dependency>
        <dependentAssembly>
          <assemblyIdentity
            type="win32"
            name="Microsoft.VC90.CRT"
            version="9.0.21022.8"
            processorArchitecture="amd64"
            publicKeyToken="1fc8b3b9a1e18e3b">
          </assemblyIdentity>
        </dependentAssembly>
      </dependency>
      
      <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
        <security>
          <requestedPrivileges>
            <requestedExecutionLevel
              level="asInvoker"
              uiAccess="false"/>
          </requestedPrivileges>
        </security>
      </trustInfo>
      
      <asmv3:application>
        <asmv3:windowsSettings xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">
          <ms_windowsSettings:dpiAware xmlns:ms_windowsSettings="http://schemas.microsoft.com/SMI/2005/WindowsSettings">false</ms_windowsSettings:dpiAware>
        </asmv3:windowsSettings>
      </asmv3:application>
      
      </assembly>

2018年7月10日 星期二

Linux 版 VSTS Agent 之 JVM 環境變數設定 - (包含SuSE Linux)

 基於協同作業、集中管理、流程自動化、降低人為失誤風險等原因,公司採用 TFS 平台來管理程式原始碼,並且使用 TFS 之 Build Agent 來組建程式碼使其可發佈、執行,但 TFS Build Agent 除了 Agent 本身之軟體外,尚需要依照程式語言的需求安裝編譯所需的軟體,才可完成編譯\組建的作業。

以下會說明:
  1. Linux 版的 Build Agent 如何安裝 Java 程式
  2. Linux 上如何設定 Java 執行所需之環境變

Java基礎說明

 我們可以在 Oracle 所屬的 https://java.com/zh_TW/ 下載 Java,但在實際下載時,可能會發現 Java 相同的版號會有 JRE、JDK 兩種不同的版本,簡單來說這兩種的分別為:
  1. JRE (Java Runtime Environment) - 可讓執行 Java 程式的軟體 - JRE 之 Wiki 網頁
  2. JDK (Java Development Kit) - 提供 Java 程式語言的開發套件 - JDK 之 Wiki 網頁
由於我們 TFS Build Agent 的目的為「組建程式」,因此我們需要安裝的是 JDK

如何下載 Linux JDK

當我們前往 JDK 下載網頁 時,先找到要下載的 JDK 版號,然後選擇下載種類為「JDK」
進入下載的選擇頁面後,請先勾選「Accept License Agreement」,才可以點下方的下載連結
Linux 平台可下載的版本有很多種,請依需求選擇要下載的版本,因為64位元作業系統相當普及了,所以一般狀況下應該選擇 x64 版,附檔名選擇 .tar.gz 的那一個

額外問題:為何不選擇 rpm ?
問題說明:因為 Linux 有許多套件版本,選擇 rpm 可能會發生以下狀況:
1. 不確定這個打包的 rpm 是否符合您所使用的 Linux
2. 若需要多個 JDK 版本並存時,rpm 安裝會互相覆蓋
3. 若有多台伺服器,基於整體環境的控管,您可能會希望「所有」Linux伺服器中,「額外安裝」的軟體要集中在一個方便管理的路徑

開始佈署 JDK

本例下載的檔案是 jdk-u8171-linux-x64.tar.gz,將下載的檔案上傳到 Linux 主機自己的 Home 目錄中,而我們要將 JDK 佈署於 /opt 目錄內執行以下指令
cd /opt ## 變更目錄為/opt
tar zxvf $HOME/jdk-8u171-linux-x64.tar.gz  ## 解開打包的壓縮檔

解開檔案後,可以看到目錄 /opt 下多了一個名稱為jdk1.8.0_171的資料夾,全名為/opt/jdk1.8.0_171
佈署的部份,這樣就完成了,後面只要再做一些環境變數的設定就可以了

Java 環境變數

JAVA執行前,一般會必需要指定兩種變數:
  1. JAVA_HOME
  2. PATH
另外,有些環境變數「可能」會被用到,:
  1. JDK_HOME
  2. JRE_HOME
  3. JAVA_BINDIR
  4. JAVA_ROOT

變數說明

  • JAVA_HOME - 就是宣告 JAVA 放置的位置,就輸入以下的指令即可:
    JAVA_HOME=/opt/jdk1.8.0_171
  • PATH - 在 Linux 內則是尋找執行指令的路徑,如果沒有設定,可能會找不到 java 這個指令,要設定 PATH 請輸入以下指令:
    PATH=$PATH:$JAVA_HOME/bin
    或是
    PATH=$PATH:$JRE_HOME/bin #(TFS Agent不適用,因為會裝JDK而不會是JRE)
    補充說明:前面等號(=)後面的 $PATH 代表,新的 PATH 變數要帶入「原本的PATH變數內容」,然後我們在後面附加上 $JAVA_HOME/bin 這個路徑
    原本是:
    PATH=/usr/local/bin:/usr/bin:/usr/bin
    改成:
    PATH=/usr/local/bin:/usr/bin:/usr/bin:/opt/jdk1.8.0_171/bin
  • JDK_HOME - 由於JDK是開發套件,在某些特殊的軟體,會偵測這個變數,一般來說會設定解壓縮的路徑
    JDK_HOME=/opt/jdk1.8.0_171
    或直接帶入 JAVE_HOME 也可以
    JDK_HOME=$JAVA_HOME
  • JRE_HOME - 類似 JDK,有時某些軟體會偵測這個變數:
    如果安裝的是JDK,會是
    JRE_HOME=$JAVA_HOME/jre
    如果安裝的是JRE,則會是
    JRE_HOME=$JAVA_HOME
    (TFS Agent不適用)
  • JAVA_BINDIR - 類似 JDK,也是只有部分軟體會偵測這個變數,調用 JAVA 的 Binary 執行檔,通常會是
    JAVA_BINDIR=$JAVA_HOME/bin
    或是
    JAVA_BINDIR=$JRE_HOME/bin
  • JAVA_ROOT - 也是類似JDK,部份軟體才會使用,如果沒有特別的需求,設定為$JAVA_HOME即可
    JAVA_ROOT=$JAVA_HOME

在 Linux 設定 Java 變數

環境變數的設定,可在登入之後下指令宣告,但是每重次新登入 Linux 都要宣告一次相當的麻煩,因此會調整 Profile 的設定,使 Java 變數在登入、啟動新 shell 時都會自動建立,大部份的 Linux,登入環境設定檔是 /etc/profile,修改這個檔案即可
SuSE 團隊將所有 Profile 相關的變數設定,依種類區分為各個獨立的檔案,放置在資料夾 /etc/profile.d 下,Java 的設定請修改 /etc/profile.d/alljava.sh

※如果使用的是 SuSE Linux,建議依循 SuSE 團隊整理與規劃的方式來進行調整,以免設定散落在各處不好尋找 & 維護
  • 一般 Linux - 請修改/etc/profile這個檔案,將以下指令附加到最後即可
    # JAVA_HOME請務必先宣告,以免後面的變數變成空值
    export JAVA_HOME=/opt/jdk1.8.0_171
    export JAVA_BINDIR=$JAVA_HOME/bin
    export JAVA_ROOT=$JAVA_HOME
    export JDK_HOME=$JAVA_HOME
    export JRE_HOME=$JAVA_HOME/jre
    export PATH=$PATH:$JAVA_HOME/bin
    
  • SuSE Linux - 請修改/etc/profile.d/alljava.sh
    原始內容:
    for JDIR in /usr/lib64/jvm /usr/lib/jvm /usr/java/latest /usr/java; do
        #....(略)
        export JAVA_HOME=$JPATH
        unset JDK_HOME
        unset SDK_HOME
    done
    
修改為:
## JDIR in 的後面插入路徑: /opt/jdk1.8.0_171 
for JDIR in /opt/jdk1.8.0_171 /usr/lib64/jvm /usr/lib/jvm /usr/java/latest /usr/java; do
  #....(略)
  export JAVA_HOME=$JPATH
  export PATH=$PATH:$JAVA_HOME/bin # ← 插入這行
  unset JDK_HOME
  unset SDK_HOME
done

驗證

修改完成,請重新登入,登入後請使用以下指令確認是否有生效 # 確認 Java 環境變數
echo $JAVA_HOME
# 確認 PATH 路徑有包含 Java 的路徑
echo $PATH

指派權限給群組MSSQLSERVER、SQLSERVERAGENT

微軟產品 (如:SQLServer) 安裝後會指派特殊的群組權限 (例如:MSSQLSERVER、SQLSERVERAGENT...),但有時因為環境調整的需求,進行檔案的遷移後,要重新指派給這種特殊群組,但是這種群組怎麼找都找不到....


其實只要搜尋群組時,切換「位置」為本機,並且輸入NT Service\MSSQLSERVERNT Service\SQLSERVERAGENT,按下「檢查名稱(C)」


這樣就找到了


2018年7月9日 星期一

Linux使用AD驗證問題

之前用Linux架了一個web服務,為了能使用辦公室進行驗證,所以讓這台Linux伺服器加入AD的網域,在設定的時候可以省一些事情
不過用了一陣子之後,就發現帳號認證會失敗,每次都是重新啟動Linux伺服器後恢復,頻率大概2 ~ 3週 (沒仔細算)
後來參考了網路文章,發現有可能是認證密碼定期變更的問題
​http://simon.rozman.si/computers/virtual/auth-failure-after-reverting-to-snapshot
所以依照前面文件的概念,可以有以下的解決方式:
重新讓Linux join domain
net join -U <AD admin帳號>

net ads join -U <AD admin帳號>

變更完畢後,透過指令檢查是否正常
wbinfo -t

另外參考微軟文件:停用網域中,電腦帳戶的密碼變更 - http://support.microsoft.com/zh-tw/kb/154501

而我自己用的方式是下面這種,並且在Cron排定作業,定期更新電腦帳戶,到目前為止就再也沒發生帳號認證失敗的問題
net ads changetrustpw -U <AD admin帳號> 

SQL Server 刪除「維護計畫」與「SQL Agent」的job Log

SQL Server的Agent如果有排定例行作業,再每次執行Job之後,都會寫一筆紀錄,時間一久之後,要查詢執行的Log時,就會發現因為Log太多導致載入時間變長
SQL Agent有個清除Log的功能,但是預設不會啟動,而且是手動、單次執行,為了提升生活品質,排定一個定期作業讓SQL自己維護,生活會多一些色彩~

我們sp_purge_jobhistory這個指令,來清除SQL Agent job的Log,指令如下:
DECLARE @Target_date datetime = CONVERT(date,DATEADD(DAY,-365,GETDATE()))
-- 清除所有job超過一年紀錄
exec msdb.dbo.sp_purge_jobhistory @job_name=NULL,@oldest_date=@Target_date
或者指定job名稱與日期:
exec msdb.dbo.sp_purge_jobhistory @job_name='Job名稱',@oldest_date='2016-03-01'
不過SQL有個用於備份的「維護計畫」,而這個作業也是與SQL Agent Log一樣的會成長,要清除它需要改用sp_maintplan_delete_log指令:
 DECLARE @Target_date datetime = CONVERT(date,DATEADD(DAY,-365,GETDATE()))
-- 清除超過一年的維護計畫紀錄
EXEC msdb.dbo.sp_maintplan_delete_log @plan_id=NULL,@subplan_id=NULL,@oldest_time=@Target_date
附註:日期計算請用DAY為單位,若用YEAR會碰到閏年2/29不執行的問題