Kamoš mal problém s Hamachi na Windows 7 – po nainštalovaní nefungovala Hamachi sieť a Hamachi zobrazovalo chybu „network adapter error“. Najprv som sa pokúšal zistiť, či je správne nastavený firewall a či Hamachi nevyžaduje administrátor­ské práva.

Za normálnych okolností Hamachi nainštaluje do systému sieťový adaptér, jednu Windows službu spúšťanú s Local System právami a GUI klienta, ktorý beží s práva bežného používateľa a využíva nainštalovanú službu. Sieťový adaptér je nastavený tak, aby poskytoval routovanie na sieť 5.0.0.1/8. Zistili sme, že sieťový adaptér nebol nainštalovaný a teda Hamachi malo problémy so správnym nainštalovaním siete. Hamachi inštaluje sieťový adaptér iba počas inštalácie – nie pri reinštalovaní – a bolo potrebné ho teda najprv odinštalovať a znovu nainštalovať. Tento postup však u kamoša nepomohol.

Inštalačný log

Najprv som sa teda pokúsil získať log z inštalácie Hamachi, či tam nie je nič podozrivé.

msiexec /log hamachi.log /i hamachi.msi

...
Action 18:30:17: InstallDriver. Installing network driver
Action 18:30:18: InstallServices. Installing new services
...

Žiadna chyba, tak som sa rozhodol vyskúšať nainštalovať ovládač pre Hamachi manuálne.

Manuálna inštalácia ovládača

Cez Device Manager kamoš dal manuálne nainštalovať sieťový adaptér s Hamachi ovládačom (%PROGRAMFILE%\LogMeIn Hamachi\hamachi.inf). Táto inštalácia však skončila veľmi divnou chybou: 0×5AA ERROR_NO_SYSTEM_RE­SOURCES – Insufficient system resources exist to complete the requested service. Na prvý pohľad sa zdá, že počítač nemá dostatok zdrojov a v tomto prípade človek najprv zisťuje, či má dosť voľného miesta na disku, alebo voľnej operačnej pamäte. Problém však bol inde a skúsili sme zapnúť v msconfig.exe diagnostické spustenie systému s iba základnými službami, aby sme vylúčili problém s nejakou inou aplikáciou. Tak isto bezúspešne a s rovnakým výsledkom.

Vďaka Process Monitoru som zistil, že inštalácia ovládačov vo Windowse je podrobne zaznamenávaná do súboru %WINDIR%\inf\setupapi.dev.log. Vyžiadal som si ho teda a nasledovala podrobná analýza a porovnanie jeho obsahu voči systému, kde sa Hamachi ovládač bezproblémov nainštaloval.

.    dvi:           {DIF_INSTALLDEVICE} 23:43:46.036
     dvi:                CoInstaller 1: Enter 23:43:46.036
     cci:                     [NdisCoinst: Enter NcipHandleInstallPreProcessing]
     cci:                     NdisCoinst: NetCfgInstanceId does not exist
     cci:                     NdisCoinst: Guid of the adapter is {DEFD4A42-3C78-4F11-AAC6-D798EF311363}
     inf:                     Opened PNF: 'C:\Windows\INF\oem2.inf' ([strings])
     cci:                     NdisCoinst: IfType from registry is 1
     cci:                     NdisCoinst: IfType 1, Characteristics 0x1, IsIrdaDevice 0, PhysicalMediaType -1, MediaType -1, IsBridge 0, FoundGuidInDownlevel 0, EnableDhcp 2
     cci:                     NdisCoinst: Connection name is Local Area Connection 35
     cci:                     NdisCoinst: NetLuidIndex does not exist
!!!  cci:                     NdisCoinst: NcipAllocateNetLuidIndex failed with error 0x5aa
     cci:                     [NdisCoinst: Exit NcipHandleInstallPreProcessing]
!!!  dvi:                CoInstaller 1: failed(0x000005aa)!
!!!  dvi:                Error 1450: Insufficient system resources exist to complete the requested service.
     dvi:           {DIF_INSTALLDEVICE - exit(0x000005aa)} 23:43:46.504

Z logu bolo vidieť, že inštalátor pri vytváraní nového sieťového adaptéru volá funkciu NcipAllocateNetLuidIndex ktorá skončí chybou. Získať informácie o tejto funkcii bolo jednoduché a zložité zároveň. Našťastie o nej existuje záznam na Internete, ale použiteľné informácie sú skryté vo veľkej kope textu zmeišaného so záznamami log súboru na fóre OSR Online.

Jeffrey Tippet z Microsoftu tam opisuje ako funkcia NcipAllocateNetLuidIndex funguje.

I don't have a good guess as to what's gone wrong, but here's some background info that might help you figure it out. (This info is an implementation detail, subject to change, but may come in handy for troubleshooting):

NDIS must allocate a (locally) unique number for each network interface, the NET_LUID. The NET_LUID consists of the ifType, paired with a unique ID number. To generate that unique ID, we keep track of the IDs that have already been assigned in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NDIS\IfTypes\[ifType] ! IfUsedNetLuidIndices (REG_BINARY) for each ifType. For example, look in \6 if your NIC is Ethernet (ifType=3D=6).

In there, there is IfUsedNetLuidIn­dices, which is (IIRC) a bitmap of the unique IDs that have been assigned to other network interfaces. Make sure this value is present and not damaged (e.g., a huge number of 0×FF's). Typically, its value will be something like 0×FF 0×01, if you have 9 NICs. Note that you can't just whack this value and replace it with something else, since then NDIS will incorrectly assign the same NET_LUID to two interfaces, and all sorts of things will break when that happens.

NcipAllocateNetLuidIndex teda pre daný typ sieťového adaptéru (v prípade Hamachi to je ifType=1) potrebuje získať LUID – Local Unique Identifier, ktorého aktuálna hodnota sa nachádza v uvedenom kľúči v Registroch. Problém môže nastať, keď je hodnota IfUsedNetLuidIndices nastavená na veľmi vysoké číslo – systém potom nemôže vytvoriť ďalšie LUID a skončí chybou 0x5AA ERROR_NO_SYSTEM_RESOURCES.

Nasledovala teda analýza tohto kľúča a dopracovanie sa (našťastie a konečne) k zdroju problému:

reg query HKLM\SYSTEM\CurrentControlSet\Services\NDIS\IfTypes\1 /v IfUsedNetLuidIndices


HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NDIS\IfTypes\1
    IfUsedNetLuidIndices    REG_BINARY    FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF

Hodnota IfUsedNetLuidIndices sa z neznámich príčin poškodila a keďže kamoš nemal v počítači nejaké špeciálne sieťové adaptéry (ifType = 1 = IF_TYPE_OTHER) tak bolo bezpečné nastaviť IfUsedNetLuidIndices na 0×00. Potom však treba reštartovať počítač. Windows si totiž načítajú pomocné LUID čísla pri štarte systému a nenačítavajú ich počas inštalácie zariadenia (overené pomocou Process Monitoru :) ). Nasledovalo už len nainštalovanie Hamachi – tento raz úspešne a bez problémov.

Po približne 24 hodinách som úspešne našiel príčinu problému, opravil chybu a získal cenné skúsenosti. A aj v tomto prípade nebolo potrebné na odstránenie problému načisto inštalovať Windows – k čomu by sa asi mnohí iní uchýlili. Samotné riešenie problému však trvalo iba pár hodín, natiahlo sa však kvôli poctivej dochádzke do školy :)

Skúšam si Microsoft CRM 4 pre svoju osobnú potrebu a aj pre školský projekt a samotná implementácia CRM nie je komplikovaná a šlo to aj bez implementačnej príručky. Beží to na Windows Serveri 2008 R2 so SQL Serverom 2008, zatiaľ bez podpory e-mailov a CRM mám v slovenskej lokalizácii. Základná testovacia prevádzka sa dá rozchodiť v pohode, ak dodržíte túto postupnosť:

1. Základom je Windows Server 2008 R2 Standard, stačí bežná inštalácia a vytvorenie domény – inak CRM inštalácia vyhodí hnusnú chybu.
2. Treba povoliť .NET Framework 3.5.1 feature, nainštalovať Web Server rolu s podporou ASP.NET a samozrejme zvoliť aj IIS 6 Management Compatibility nástroje.
3. CRM 4 ešte vyžaduje mať nainštalovanú Indexing Services, takže z role File Services treba nainštalovať Windows Server 2003 Compatibility nástroje. Inak bude CRM inštalátoru úplne pri konci vadiť, že služba cisvc nie je nainštalovaná.
4. Nasleduje SQL Server 2008, treba nainštalovať databázový engine a Reporting Services. Pre každú službu je vhodné vytvoriť samostatné konto v doméne. Po nainštalovaní treba aplikovať SP1, aby bol SQL Server kompatibilný s R2 verziou Windowsov. Reporting Services stačí nastaviť s predvolenými hodnotami.
5. V tejto fáze už nie je problém nainštalovať CRM 4 na predvolený IIS Web Site, pri nastavovaní URL pre Reporting Service si treba dať pozor a použiť URL pre Reporting Service, nie pre Reporting Manager. Pri otázke na adresu e-mailového serveru som vynechal jeho nastavenie, pretože potom sa CRM tvárilo, že nevie nájsť Exchange server. V testovacej prevádzke sa dá zaobísť aj bez podpory e-mailov.
6. Slovenský jazykový balíček pre CRM nájdete v Microsoft Download centre: Jazykový balík k aplikácii Microsoft Dynamics CRM 4.0
7. CRM sa samo neaktualizuje a je potrebné zohnať si Update Rollup 10, v prípade použitia Windows Serveru 2008 R2 samozrejme treba použiť aktualizácie určené pre amd64 architektúru. Aktualizácie treba nainštalovať v českej aj slovenskej verzii.
8. Správca CRM musí v časti Nastavení > Správa > Jazyky povoliť slovenský jazykový balíček, čo bude trvať dlhšiu dobu – SQL Server po tejto akcii začne pekne vyťažovať procesor.
9. Používatelia si môžu pomocou odkazu Nástroje na hlavnej lište zobraziť Možnosti a tam si na karte Jazyky zmeniť jazykovú mutáciu.

A už sa stačí len zabávať s CRM a zlepšovať si vzťahy so zákazníkmi :)

Objavil som blog nášho učiteľa Informatickej bezpečnosti a spomenul tam veľmi dôležitý prípad v používaní (budúcej) Elektronickej zdravotnej karty občana (EZKO): lekári by mali mať prístup k EZKO – čo je legitímne pokiaľ je to teda ošetrujúci lekár pacienta, avšak veľkým problémom môžu byť správcovia, ktorí budú udržiavať počítače a softvér u lekárov. Často sú informačné systémy navrhnuté tak, že správcovia majú prístup všade – aj k faktúram na ekonomickom oddelení, aj k návrhom zmlúv z marketingu a tak podobne.

Pevne verím že EZKO nebude nepodarok a prístup administrátorov do systému bude vyriešený tak, že síce budú mať možnosť riešiť problémy v ňom, ale v žiadnom prípade nebudú môcť pristupovať k údajom o pacientoch.

Čítam si knižku Configuring Windows Server 2008 Network Infrastructure a učím sa používať príkaz netsh na správu sieťových rozhraní vo Windowse. Po veľmi dlhej dobe som konečne našiel príkaz ktorým sa dá zmeniť názov sieťového pripojenia. Tie štandardné názvy sú príliš dlhé: Local Area Connection a v laboch preferujem mať popisné názvy ako WAN pre pripojenie do internetu na serveri a Contoso LAN na lokálnych sieťových adaptéroch. Doteraz som to menil len cez Explorera, avšak už môžem zvýšiť svoju produktivitu vďaka netsh:

netsh>interface
netsh interface>set interface ?
...
Examples:
      set interface name="Local Area Connection" newname="Connection 1"

netsh interface>set int name="Local Area Connection" newname="Contoso LAN"
An interface with this name is not registered with the router.

netsh>

Dosť nečakaná chyba An interface with this name is not registered with the router. prekazila moje plány na zmenu názvu tak som radšej rýchlo prešiel na nastavovanie IPv6 adries, aby som sa nezdržoval v takúto neskorú hodinu.

netsh interface ipv6>set add "Local Area Connection" fd00::2/64
The requested operation requires elevation (Run as administrator).

Príčina chyby bola hneď jasná: nie som administrátor a Windows 7. Pred chvíľou som nastavoval IPv6 adresu na Windows 2008 R2 Serveri kde tento príkaz zbehol v pohode. User Account Control je po nainštalovaní Windowsu zapnuté pre všetkých administrátorov okrem štandardného konta Administrator. Je tu ale rozdiel medzi serverovým a klientským Windowsom:

• Serverový OS: počas inštalácie nastavíte heslo a prihlasujete sa pod Administrator
• Klientský OS: počas inštalácie zadáte názov konta a heslo a prihlasujete sa pod ním

Príkazový riadok som samozrejme zabudol spustiť s administrátor­skými právami a bohužial vo Windowse normálne nie je príkaz sudo :( Spustenie novéhopríkazového riadku s riadnymi právami umožnilo používať netsh na konfiguráciu Windowsu a zmena mena adaptéru zbehla v pohode. Škoda len, že niekto v MS si nedal tú námahu naprogramovať do všetkých častí netshu, ktoré upravujú systém, kontrolu práv.