Change default WSUS port from 8530 to 80 on Windows Server 2012

After WSUS installation on Windows Server 2012 I discovered that it’s running on port 8530, different than on older version of Windows (it was using port 80 from beginning). But what’s more interesting it was running ONLY on IPv6 interface! Switching binding configuration in IIS doesn’t help.

I could stand switching port – it’s nothing hard with GPO, but IPv6 only configuration was not acceptable.

After googling for some time I found one command that solved my problems by switching WSUS to older behavior and run it on port 80 (on default website).

Just run on elevated command line:

C:\Program Files\Update Services\Tools\WSUSutil usecustomwebsite false

After half a minute WSUS was working like a charm 🙂

Source:
http://social.technet.microsoft.com

Manage Windows 8.1 and Windows Server 2012 R2 in WSUS 3.0

After connecting few computers with Windows 8.1 to domain we found that these computers are not recognized or recognized as Windows 6.3 (which is true) on WSUS 3.0 running on Windows Server 2008. The bad thing was that they can’t properly report to WSUS and get updates from it.

I found that there are two updates that have to be installed (but they’re not working without additional steps):

After installation of second update there are two additional steps that have to be performed to get WSUS working:

Reindex the WSUS Database

To do this perform these steps:

  • Copy sript from this site to file named WsusDBMaintenance.sql
  • Install sqlcmd from this site – search for file named like “SQLServer2005_SQLCMD” with proper architecture (x86/amd64/ia64)
  • run:
    sqlcmd -S np:\\.\pipe\MSSQL$MICROSOFT##SSEE\sql\query -i C:\path to script saved in first point\WsusDBMaintenance.sql
  • Use WSUS Server Cleanup Wizard

Done. Your WSUS will not recognize 8.1 clients but will work with them and serve updates.

Source:
http://social.technet.microsoft.com/Forums/en-US/559fe878-e2a2-4ec6-9d91-55ea1b67caef/manage-windows-81-windows-server-2012-r2-on-wsus-30?forum=winserverwsus

DFS – sprawdzanie statusu replikacji

Ostatnio zbyt dużo grzebię przy “windach” – ale cóż, czasem trzeba. Ostatnio ustawiałem DFS’a z replikacją dla dwóch sporych zasobów i jedna z rzeczy, o którą się rozbiłem to brak jakiegokolwiek podglądu tej synchronizacji z GUI. Ale znalazłem jedno polecenie, które działa w shellu (choć to się chyba batch tutaj nazywa) od Windows Server 2008 R2:

dfsrdiag ReplicationState /member:nazwaservera

Polecenie co prawda nie podaje postępu procentowego ale można zobaczyć “czy coś jeszcze się synchronizuje” i czy nie ma żadnych błędów. Jeżeli to polecenie to za mało to można spróbować bardziej gadatliwej wersji:

dfsrdiag ReplicationState /member:nazwaservera /all

GPO: Instalacja GIMP’a 2.8

Raz na jakiś czas trzeba coś niestandardowego wrzucić do instalacji w Active Directory a że nie wszystkie aplikacje mają dostępne paczki MSI to trzeba się nieco natrudzić.

Poniżej wrzucam skrypt, który instaluje GIMP’a 2.8 z domyślnego instalatora (wersja InnoSetup) przy okazji odinstalowując wcześniejsze wersje zainstalowane ręcznie.

Zapisujemy poniższy kod jako np. gimp-install.cmd

@echo off
REM  Installs GIMP
cls
echo ----------------------------------------------------
echo .
echo .
echo .      Installing/Updating GIMP - Please Wait
echo .
echo .
echo ----------------------------------------------------
REM Test if actual
IF exist "%ProgramFiles%\GIMP\bin\gimp-2.8.exe" GOTO SkipInstall

REM Exit the application
taskkill.exe /F /FI "IMAGENAME eq gimp-2.8.exe" >nul

REM Uninstall existing GIMP version, delete folder
if exist "%ProgramFiles%\GIMP 2\uninst\unins000.exe" "%ProgramFiles%\GIMP 2\uninst\unins000.exe" /VERYSILENT
:: Wait for 20 seconds
ping -n 40 127.0.0.1 > NUL
if exist "%ProgramFiles%\GIMP 2\" rd "%ProgramFiles%\GIMP 2\" /Q /S

REM Install new version
"\\serwerplikow.local\Instalki\GIMP\gimp-2.8.4-setup.exe" /VERYSILENT /NORESTART /DIR="%PROGRAMFILES%\GIMP 2.8"

REM Skip installation if acctuall
:SkipInstall

REM Return exit code to SCCM
exit /B %EXIT_CODE%

Tworzymy nową regułkę GPO i zmierzamy do: Computer Configuration\Policies\Windows Settings\Scripts\Startup
W nowym okienku wybieramy Show Files…
Wklejamy plik skryptu do tego folderu i teraz możemy dodać go w tym samym oknie (Add…) – dzięki wrzuceniu skryptu w tym miejscu będzie się on automatycznie replikować na inne kontrolery. Skrypt będzie co prawda uruchamiany przy każdym starcie komputera ale pierwszy warunek będzie sprawdzać czy aplikacja jest zainstalowana więc nie spowolni to znacznie startu.

Skrypt znalazłem gdzieś na sieci ale nie mogę namierzyć źródła.

Apache: mod_authnz_ldap z Active Directory

Gdy już się dorobi systemu Active Directory wygodnie jest wykorzystać jego bazę użytkowników do autoryzacji w różnych miejscach, np. do pewnych “tajnych i tajniejszych” stron w Apache. Najprościej można to zrobić z wykorzystaniem LDAP.

Warto sprawdzić czy i jak możemy dostać się do kontrolerów. Gdy już mamy wszystkie potrzebne parametry konfigurujemy Apachego – na początek aktywujemy moduły:

a2enmod ldap
a2enmod authnz_ldap

Teraz możemy edytujemy globalny plik konfiguracyjny mod_ldap’a by ustawić nieco cache’y (bardzo przydatne). Wartości można dostosować do potrzeb ale przykładowe powinny wystarczyć na początku:

LDAPSharedCacheSize 500000
LDAPCacheEntries 1024
LDAPCacheTTL 600
LDAPOpCacheEntries 1024
LDAPOpCacheTTL 600
<Location /ldap-status>
  SetHandler ldap-status
  Order deny,allow
  Deny from all
  # Allow from 127.0.0.1 ::1
  Allow from 192.168.1.15/32
  Satisfy all
</Location>

Warto zwrócić uwagę na drugą część – można aktywować podgląd statusu mod_ldap’a co bywa przydatne na etapie testów (np. by zobaczyć kto aktualnie jest zalogowany) – ja umożliwiłem dostęp ze swojego zdalnego komputera. Teraz restart Apachego aby wszystko się załadowało:

invoke-rc.d apache2 restart

Środowisko mamy gotowe, możemy skonfigurować vhosta. Poniższe opcje wrzucamy np. do klauzuli <Directory> lub <Location>:

Authtype basic
Authname "Zaloguj sie kontem domenowym"
AuthBasicProvider ldap
AuthzLDAPAuthoritative Off
AuthUserFile /dev/null
AuthLDAPUrl "ldap://server1.nazwadomeny.local:389 10.0.0.32:389/DC=nazwadomeny,DC=local?sAMAccountName?sub?(objectClass=person)" NONE
AuthLDAPBindDN "CN=kontodomenowe,OU=System Accounts,DC=nazwadomeny,DC=local"
AuthLDAPBindPassword "haslo konta domenowego"
Require valid-user
# Require ldap-dn ou=Jakies przykladowe OU

Najważniejsze parametry to:

  • AuthLDAPUrl – tutaj podajemy parametry do połączenia LDAP, w pierwszej części możemy podać kilka serwerów by mieć backup, później korzeń od którego będzie rozpoczynane przeszukiwanie drzewa (tutaj cała domena), na końcu filtry,
  • AuthLDAPBindDN – konto którym autoryzujemy się do kontrolera by móc przeszukiwać na nim obiekty (podane jako ścieżka LDAP),
  • AuthLDAPBindPassword – hasło do powyższego konta,
  • Require ldap-dn – można nie tylko sprawdzać czy użytkownik jest prawidłowy ale również czy jest w pewnym OU, grupie itd…

Teoretycznie wszystko jest poprawnie ale za cholerę nie chciało działać dopiero dodanie do /etc/ldap/ldap.conf opcji: REFERRALS off sprawiło że autoryzacja działa poprawnie – oneliner by to uzyskać:

echo "REFERRALS off" >> /etc/ldap/ldap.conf

Ja mam Apachego 2.2 i jest to jedyna opcja by uzyskać ten efekt. W wersji od 2.4 jest dodatkowa opcja LDAPReferrals, która pozwala na zmianę tego zachowania wprost z konfiguracji Apachego.