Een leuke voor de vroege morgen, het Windows logboek roept eerst:

A protocol other than the Microsoft Virtual Network Switch Protocol has been bound to NIC ‘Broadcom BCM5709C NetXtreme II GigE (NDIS VBD Client) #11′ but the NIC is being used by a virtual switch.

Om vervolgens te roepen:

The virtual switch protocol is not bound to NIC ‘Broadcom BCM5709C NetXtreme II GigE (NDIS VBD Client) #11′ but the NIC is being used by a virtual switch.

Nu moet ik eerlijk bekennen dat ik er in eerste instantie overheen heb gelezen, maar eigenlijk word hier geroepen “Er is een virtual switch die deze adapter gebruikt maar er zijn ook andere protocollen gedefinieerd” om vervolgens te roepen “Een virtual switch is geconfigureerd met deze adapter, maar het virtual switch protocol is niet gebonden aan deze adapter”. Wat nu?

Omdat ik hem in eerste instantie verkeerd had gelezen heb ik eerst het virtual network van deze hyper-v host leeg gemaakt (en de host zelf leeg gemoved binnen het cluster) om vervolgens de virtual switch te verwijderen en opnieuw aan te maken. Dit mocht niet baten. Na wat verder speurwerk kwam ik de tool “nvspbind” en “nvspbind scrub” tegen. De laatste is nogal erg rigoureus “schonen” en daar waren we nog niet. Dus begonnen met nvspbind. Door de optie /n te gebruiken krijg je een redelijk schoon adapter overzicht. Zie hier een uitgezoomd stukje:

{E2943FB1-5676-492C-ACED-7F4D15AAAE0D}
“b06bdrv\l2nd&pci_163914e4″
“Broadcom BCM5709C NetXtreme II GigE (NDIS VBD Client) #11″
“HyperV-iSCSIB-iSCSI 172.20.10.x”:

 {60B09A58-B959-44A0-95BD-7A21AC86F112}
“b06bdrv\l2nd&pci_163914e4″
“Broadcom BCM5709C NetXtreme II GigE (NDIS VBD Client) #34″
“HyperV-CustomerVswitch1″:

En daar viel mij al vrij snel op: “vSwitch is adapter 34” en de iscsi is adapter “11”. Na het extra controleren blijkt dat adapter 34 helemaal niet in gebruik zou moeten zijn maar Hyper-V dit wel denkt. Na een gedetailleerd overzicht doormideel van puur nvspbind met de adapter guid (b.v.:  {E2943FB1-5676-492C-ACED-7F4D15AAAE0D}” zien we het volgende overzicht.

{E2943FB1-5676-492C-ACED-7F4D15AAAE0D}
“b06bdrv\l2nd&pci_163914e4″
“Broadcom BCM5709C NetXtreme II GigE (NDIS VBD Client) #11″
“HyperV-iSCSIB-iSCSI 172.20.10.x”:
   disabled: ms_netbios       (NetBIOS Interface)
   disabled: ms_server        (File and Printer Sharing for Microsoft Networks)
   disabled: ms_pacer         (QoS Packet Scheduler)
   disabled: ms_ndiscap       (NDIS Capture LightWeight Filter)
   disabled: ms_wfplwf        (WFP Lightweight Filter)
   disabled: ms_msclient      (Client for Microsoft Networks)
   disabled: ms_tcpip6        (Internet Protocol Version 6 (TCP/IPv6))
   disabled: ms_netbt         (WINS Client(TCP/IP) Protocol)
   disabled: ms_smb           (Microsoft NetbiosSmb)
   enabled:  ms_tcpip         (Internet Protocol Version 4 (TCP/IPv4))
   disabled: ms_lltdio        (Link-Layer Topology Discovery Mapper I/O Driver)
   disabled: ms_rspndr        (Link-Layer Topology Discovery Responder)
   disabled: ms_pppoe         (Point to Point Protocol Over Ethernet)
   disabled: ms_ndisuio       (NDIS Usermode I/O Protocol)
   disabled: vms_pp           (Microsoft Virtual Network Switch Protocol)
   disabled: brcm_blfp        (Broadcom Advanced Server Program Driver)

Kortom, het hele virtual switch protocol staat niet aan. Nu word die leuk. Met Powershell wilde ik kijken maar kon ik niet zo snel de Hyper-V modules importeren en ik wist even niet of ik daar nu SCVMM voor moest hebben dus eerst maar een andere kleine test gedaan en dat is met nvspbind het virtual switch protocol enabled en disabled op de host. Wat testen gedaan door vm’s te moven en de melding kwam niet meer, tevens nog de host een reboot gegeven en daar was die weer. Ach, dan kunnen we in ieder geval de nvspcrub tool testen . Deze tool getest maar het leek nog niet weg te zijn, zelfs niet met de /p (purge all virtual switches) maar dit konden ook meldingen zijn van enkele seconden voor het runnen van de tool. Omdat de tijd begon te dringen toch ook maar het virtual netwerk aan de adapter 11 gekoppeld en weer verwijderd. Nu de host weer een reboot.

Alles werkt weer zoals het zou moeten horen. Mijn persoonlijke mening is dat het opnieuw aanmaken van een virtual switch op de 11 adapter het probleem opgelost heeft, desalniettemin vind je in deze blog wel alle documentatie waarmee je dit probleem in iedere situatie mee op moet kunnen lossen.

Met de komst van VMWare workstation is er ondersteuning voor Windows 8. Aanvullend was dit voor mij direct een “hoe zat het ook alweer met virtual machine support vanuit Microsoft voor Windows 8”. Gelukkig, het is er!

Zoals de ras techneuten / virtualisatie specialisten wel weten was daar vroeger al Virtual Machine Manager van Microsoft en uiteraard VMWare Workstation (goed Oracle VirtualBox heeft ook zijn afzetmarkt maar valt in mijn ogen buiten de boot vanwege de concurrentie/alternatieven met de komst van Hyper-V voor Windows 8). Deze laatste kan uiteindelijk meer wanneer je lokaal clustering wil testen, shared disks, enz. maar heb je een Windows 8 Pro of Enterprise licentie krijg je standaard gratis Hyper-V voor Windows 8 erbij. De configuratie en management tools zijn hetzelfde als voor een 2008 of 2012 Hyper-V server wat het erg prettig werken maakt.

De installatie verloopt via: “Programma’s en Onderdelen” in het configuratiescherm waar je kan kiezen voor: “Windows onderdelen in- of uitschakelen”. Voor meer informatie:

http://blogs.msdn.com/b/olivnie/archive/2013/01/18/hyper-v-on-client-windows-8-pro.aspx

Apple Airplay, fantastisch, knap werk! Helaas is het protocol wat minder geniaal maar gelukkig kunnen we met apparatuur van Cisco erg veel!  Het Apple Airplay protocol over een wifi netwerk versturen is niet zo logisch als het lijkt. Eenzelfde geval is bijvoorbeeld, recentelijk bij een klant ervaren, dat een printer achter een wifi bridge hangt en “in ene” niet meer bereikbaar is. Wat bleek, met de hand een ARP entry toevoegen deed alles weer werken. Echter is dit niet wenselijk.

Waar komt het door? Simpel gezegd is dat ARP discovery niet over alle apparaten gaan om o.a. broadcast storms in te perken. Hiervoor is op een gegeven ogenblik multicast gekomen zodat het in te perken valt. Maar goed, hoe configureer je dit?

Op een Cisco Wireless LAN Controller dien je onder de controller properties “Multicast” te enablen. Vervolgens dien je ook een multicast adres te kiezen: “239.1.1.1” is zo’n vrij te gebruiken adres. Echter hebben de nieuwe Cisco WLC na de firmware upgrade gewoon een “enable Apple Bonjour” gateway vinkje wat dit ook oplost.

Uiteraard geld dit ook voor andere apparaten en routers.

Uw Wi-Fi netwerk is wellicht nog voorzien van een WPA2 wachtwoord, of misschien nog wel erger, een WEP key. In het laatste geval verdient het de aanbeveling deze te
upgraden naar WPA2 encryptie en misschien nog wel een stap verder. U meld al
aan met uw gebruikersnaam en wachtwoord op het netwerk, VPN oplossing, Webmail
maar waarom niet voor de Wi-Fi? Voordeel is dat een medewerker die uit dienst
gaat zijn account word uitgeschakeld en direct de toegang tot de Wi-Fi word
ontzegd.

En één van de mooie dingen is dat u wellicht alles al in huis heeft. Hoe werkt het? Zoals in de afbeelding zichtbaar is dient er een NPS server ingericht te worden. Deze bepaald wat uw beleid is met betrekking tot wie wel en geen toegang heeft tot de Wi-Fi of de verschillende Wi-Fi netwerken. Het account dient bijvoorbeeld lid te zijn van de groep “Wi-Fi gebruikers” of de groep “Smartphones”. Vervolgens configureren we de acces points of uw Wireless LAN controller dat deze communiceert met uw NPS server welke op haar beurt weer de verificatie doet richting het Active Directory domein.

Hoe werkt het? Net als nu, uw medewerker kies het draadloze netwerk op zijn of haar device en in plaats van één invult veld “wachtwoord” krijgt deze er nu 2 te zien: “gebruikersnaam en wachtwoord”.

Belangrijke voetnoot: De NPS server is een standaard onderdeel van Windows Server.

Je wilt centraal authenticatie doen voor b.v. een router, netwerk device, 802.x, noem maar op. Tuurlijk kan je de Active Directory gebruiken maar dit is niet altijd mogelijk. Niet ieder apparaat ondersteund een LDAP client. Om maar niet te spreken van licenties.

Je zal al snel op Radius of Tacacs+ uitkomen, oké die laatste wat minder snel maar hij zal de revue passeren. Maar wat zijn nou de verschillen, en waarom worden vaak beiden ondersteund en benoemd terwijl de uiteindelijk oplossing hetzelfde resultaat bied. Hieronder zijn de belangrijkste verschillen benoemd:

• RADIUS gebruik UDP waar TACACS+ TCP gebruikt
• RADIUS encrypt het wachtwoord alleen tijdens verzenden waar TACACS+ de gehele sessie encrypt
• RADIUS combineert authenticatie en authorizatie waar TACACS+ deze scheid en apart ook nog accountability anbied
• RADIUS is is beperkt in toegangs niveau’s (privelege voor de Cisco kenners) waar TACACS+ 15 levels beschikbaar heeft.
• RADIUS is een open standaard en dus veel meer in gebruik / support en TACACS+ is Cisco eigendom (de Cisco ACS server)
• RADIUS is lichter en vereist dus minder resources van de hardware van de clients (CPU, MEMORY) waar TACACS+ meer resources vereist.

En wat moet ik nu kiezen? Lees de verschillen, weeg vooral de security niveaus en sessie encryptie af. In de praktijk zal je vrijwel altijd RADIUS kiezen.TIP! Microsoft’s NPS (Network Policy Server) ondersteund dit. Er zit wel een verschil in het aantal clients tussen de Windows 2008 Server Edities.

Het nieuwe Microsoft besturingssysteem is standaard niet voorzien van een start menu. Persoonlijk vind ik dat wij er als professionals aan moeten wennen maar wanneer ik bijvoorbeeld iemand als mijn vader thuis een computer ga geven zonder start menu word het wel erg lastig om nog te kunnen wennen hieraan. Derhalve toch maar de zoektocht gestart en een erg mooi (Gratis) alternatief kunnen vinden.

Kijk eens op: http://sourceforge.net/projects/classicshell/?source=dlp

Voor een goed alternatief start menu. Tip, voor de mensen die automatisch naar de desktop switchen in plaat van het “Metro” begin scherm, dit hoeft na installatie ook niet meer. Ik geloof dat ik er zelf toch ook wel blij mee ben.

Vandaag e.e.a. besproken bij een klant die vermoedelijke iets in zijn netwerk heeft. Soms zijn er haperingen dan wel vertragingen dien niet direct verklaarbaar zijn. Uiteraard heeft Adfocom daar schitterende tools voor om dit real-time te laten controleren en rapportages over te laten genereren. En niet alleen op “uptime” en “bandwith”, maar dit kan ook op “packet-loss, latency, delay” enz.

Dit is niet altijd mogelijk en soms wil je direct gaan monitoren. Daarom een simpel smerig scriptje welke dit regelt. De controle en logging gebeuren via een .cmd file en een .txt file.

Begin code:

@echo off
setlocal enabledelayedexpansion
set hostIP=192.168.1.237
:loop
set pingline=1
for /f “delims=” %%A in (‘ping -n 1 -w 250 -l 255 %hostIP%’) do (
REM      for on screen printing
echo !logline! | find “TTL=”>nul || echo !logline!
if !pingline! equ 2 (
set logline=!date! !time! “%%A”
echo !logline! | find “TTL=”>nul || echo !logline! >> pinglog.txt
)
set /a pingline+=1
)
choice /N /T 1 /D Y >nul
goto loop

Eind code:

Zo nu en dan krijgen we de vraag, mijn nieuwe tablet doet het niet op de wifi. Of mijn laptop is zo traag op internet. Dan wel de wens om een “snellere” verbinding te realiseren dan er momenteel aanwezig is op de wireless omgeving.

Zo logisch als het klinkt dat een Computer of Virusscanner een update behoeft voor de continue werking, geld dit ook voor wireless apparatuur. Zowel de client als het accesspoint zijn voorzien van software welke de werking mogelijk maken. Dat dit niet altijd bijgehouden word is begrijpelijk, maar wanneer er storingen zijn is het advies hier te beginnen. Aanvullend kunnen updates ook hogere snelheden realiseren door een betere implementatie van de wifi standaarden.

Wanneer u gebruik maakt van “losse” accesspoints kan het bij uitbreiding, of intensiever gebruik, van de wireless omgeving de afweging waard zijn om de omgeving te upgraden doormiddel van een Wireless LAN Controller. De toegevoegde waarden en verbetering van functionaliteit en beheer lichten wij u graag toe. Tevens kan de WLAN controller centraal alle accesspoints in één keer voorzien van de laatste software versie en diepgaande logging van uw wireless omgeving.

Waar komt het plaatje vandaan? Het laatste voorval was nadat een klant gebruik wilde maken van de nieuwe aangeschafte Galaxy Tab 10.1

Vandaag diende er 2 accesspoints van Leightweight (WLAN controller modus) omgeconfigureerd te worden naar Autonomous (zelfstandig) modus. Omdat ik het op moest zoeken en moest wachten gelijk maar even een artikel aan gewaagd voor volgende keer.

Download tftpd vanaf http://tftpd32.jounin.net/ (mijn persoonlijke favoriet).
Ga met je laptop en AP op één switch zitten.
Geef je laptop een  vast ip, te weten: 10.0.0.2 / 255.255.255.0
Start tftpd.exe en pas de TFTP Timeout setting aan naar 60 seconden.

Vervolgens download je de laatste IOS versie voor dit AP en plaats je in de root van de TFTP server. Hernoem de IOS versie naar het type van het accesspoint. In het geval van een 1242 was dit:

c1240-k9w7-tar.default

(let op, dit kan je ook nazien nadat je de onderstaande stappen hebt gedaan).

Maak het accesspoint stroom loos
Zet de spanning er weer op en houd nu de “mode” button minstens 30 seconden ingedrukt.
Wanneer je de console kabel aangesloten hebt zitten zie je op den duur voorbijkomen:

ethernet link up, 100 mbps, full-duplex
Ethernet port 0 initialized: link is up
button is pressed, wait for button to be released…
button pressed for 49 seconds
process_config_recovery: set IP address and config to default 10.0.0.1
process_config_recovery: image recovery
image_recovery: Download default IOS tar image tftp://255.255.255.255/c1240-k9w7-tar.default
examining image…tftp://255.255.255.255/c1240-k9w7-tar.default: no such file or directory
ERROR: Failed to open archive file tftp://255.255.255.255/c1240-k9w7-tar.default

Kortom, mijn geval heb ik bewust even de TFTP uit gezet zodat deze niet gevonden kan worden. Voordeel is, wanneer je niet weet hoe de file zou moeten heten het nu wel in het beeld staat.

Sinds de komst van Server 2012 volg ik dit al op de voet en heb inmiddels voldoende achtergrond info. Een aantal praktijk installaties, maar desondanks altijd de hoop gehouden dat er uiteindelijk een mooi migratie scenario zou komen van een Hyper-V 2008R2 cluster naar een Server 2012 cluster. Helaas. Tuurlijk zijn er mogelijkheden en tools genoeg, maar het is jammer om te zien dat het bij VMWare een fluitje van een cent is zonder downtime en dat dit bij Server 2012 toch iets gecompliceerder is.

Kort door de bocht. Een Mixed-mode environment bestaat niet. Punt.