"The Blu Tree"

Knowledge. Shared.

NAP – How to connect workstations using Network Access Protection to a RADIUS server

Posted by on 31 May, 2015 in Cisco Meraki, Microsoft, Windows Server | 0 comments


Radius Server – Windows server 2012 R2 Standard with NAP installed and configured

Wireless – Cisco Meraki M32 Wireless Access Points connected to a MX firewall.




When Clients are connecting to a Wireless network using 802.11 or WPA2 Enterprise they are showing in the event viewer on the radius server  as Non-NAP Capable and quarantined.


Event ID: 6276

Authentication Details:

Connection Request Policy Name:   NAP 802.1X (Wireless)

Network Policy Name:  NAP 802.1X (Wireless) Non NAP-Capable

Authentication Provider:  Windows

Authentication Type:  PEAP

EAP Type:  Microsoft: Secured password (EAP-MSCHAP v2)

Quarantine Information:

Result:  Quarantined




This occurs if the client is not setup correctly causing them to show as Non-NAP Capable.




There are a few Settings that need to be enabled on the client and most/all of the settings below can be pushed out by a group policy.


1) Make Sure the Network Access Protection Service is running



2) As there is a delay when the wireless network connects you need to start the NAP service after the wireless.


This can be done by going to the following entry in the registry and making the change below:


Update the DependOnService entry and add napagent.


The entry should look similar to the below.  You will need to reboot the client for the registry change to take effect.

NOTE: The service WCMSVC below is only required for Windows 8 workstations. 



3) Enable the Following Setting in:

GPO Manager > Computer Configuration > Policies > Windows Settings > Security Settings > Network Access Protection > NAP Client Configuration > Enforcement Clients




4) On the Client Machine go to Network and Sharing

Select adaptor settings > Right click the Wireless connection once connected to the wireless connection > Select Status > Wireless Properties > Security Tab > Settings > Select Enforce Network Access Protection > Select OK on all open windows.



Read More

VMware – Purple Screen (PSOD) Exception 14 in world

Posted by on 26 Apr, 2015 in Virtualisation, VMware | 0 comments


ESXi hosts using version 5.1.0 (Build 799733) purple screen with the error below

2015-03-03T11:41:32.034Z cpu4:8196)@BlueScreen: #PF Exception 14 in world 8196:idle4 IP 0x41801699c3c6 addr 0x0

2015-03-03T11:41:32.034Z cpu4:8196)Code start: 0x418016800000 VMK uptime: 0:01:30:50.071

2015-03-03T11:41:32.035Z cpu4:8196)0x41220011b568:[0x41801699c3c6]E1000PollRxRing@vmkernel#nover+0xdb9 stack: 0x41220011b5c8

2015-03-03T11:41:32.035Z cpu4:8196)0x41220011b5d8:[0x41801699fdd3]E1000DevRx@vmkernel#nover+0x18a stack: 0x412200000000

2015-03-03T11:41:32.036Z cpu4:8196)0x41220011b678:[0x41801693cf40]IOChain_Resume@vmkernel#nover+0x247 stack: 0x310

2015-03-03T11:41:32.037Z cpu4:8196)0x41220011b6c8:[0x41801692c154]PortOutput@vmkernel#nover+0xe3 stack: 0x41000b215a00

2015-03-03T11:41:32.038Z cpu4:8196)0x41220011b728:[0x418016e3976f]EtherswitchForwardLeafPortsQuick@<None>#<None>+0xd6 stack: 0x360011b

2015-03-03T11:41:32.039Z cpu4:8196)0x41220011b928:[0x418016e3afd8]EtherswitchPortDispatch@<None>#<None>+0x13bb stack: 0x412200000018

2015-03-03T11:41:32.039Z cpu4:8196)0x41220011b998:[0x41801692b337]Port_InputResume@vmkernel#nover+0x146 stack: 0x41000b2d2b00

2015-03-03T11:41:32.040Z cpu4:8196)0x41220011b9e8:[0x41801692cab2]Port_Input_Committed@vmkernel#nover+0x29 stack: 0x10011ba68

2015-03-03T11:41:32.041Z cpu4:8196)0x41220011ba68:[0x41801696b541]Vmxnet3VMKDevTQDoTx@vmkernel#nover+0x2f8 stack: 0x41220011baf8

2015-03-03T11:41:32.042Z cpu4:8196)0x41220011bab8:[0x41801696c968]Vmxnet3VMKDev_AsyncTx@vmkernel#nover+0xd7 stack: 0x41220011baf8

2015-03-03T11:41:32.043Z cpu4:8196)0x41220011bb28:[0x4180169518a3]NetWorldletPerVMCB@vmkernel#nover+0xae stack: 0x418016a05d78

2015-03-03T11:41:32.044Z cpu4:8196)0x41220011bca8:[0x41801690af2b]WorldletProcessQueue@vmkernel#nover+0x486 stack: 0x41220011bd58

2015-03-03T11:41:32.045Z cpu4:8196)0x41220011bce8:[0x41801690b5a5]WorldletBHHandler@vmkernel#nover+0x60 stack: 0x10041220011bd68

2015-03-03T11:41:32.045Z cpu4:8196)0x41220011bd68:[0x4180168207fa]BH_Check@vmkernel#nover+0x185 stack: 0x41220011be68

2015-03-03T11:41:32.046Z cpu4:8196)0x41220011be68:[0x4180169bc9dc]CpuSchedIdleLoopInt@vmkernel#nover+0x13b stack: 0x41220011be98

2015-03-03T11:41:32.047Z cpu4:8196)0x41220011be78:[0x4180169c66ae]CpuSched_IdleLoop@vmkernel#nover+0x15 stack: 0x4

2015-03-03T11:41:32.048Z cpu4:8196)0x41220011be98:[0x41801684f6ce]Init_SlaveIdle@vmkernel#nover+0x49 stack: 0x0

2015-03-03T11:41:32.048Z cpu4:8196)0x41220011bfe8:[0x418016ae1f86]SMPSlaveIdle@vmkernel#nover+0x31d stack: 0x0

2015-03-03T11:41:32.051Z cpu4:8196)base fs=0x0 gs=0x418041000000 Kgs=0x0





This is down to VM’s having either of the E1000 or E1000E network cards.  The error can an occur when:

  • creating multiple VM’s with E1000/E1000E network cards
  • The error can appear when try and vMotion these VM’s host to host
  • Upgrading VMware Tools




  • Upgrade to ESXi 5.1 Update 2 or later
  • As a work around you can follow the steps below:
    1. Install vSphere PowerCLI
    2. Run the command


Connect-VIServer (Server IP address/Hostname)


Connect-VIServer vCenter01.domain.com

3. Run the command

ForEach( $VM in (Get-VM) ) { $VM|Where{ $VM|Get-NetworkAdapter|Where{ $_.ExtensionData -like “*e1000*” } } }


4. This will bring up a list VM’s containing those network cards. You will need to remove the network cards from these VM’s and replace them with VMXNET3 network cards.



Read More

Office 365 – Emails marked as private are not appearing in a shared mailbox

Posted by on 9 Mar, 2015 in Microsoft, Office 365 | 2 comments


Exchange 2010 and Office 365 Hybrid deployment with multiple shared mailboxes on office 365



We have a shared mailbox for a number of users and if anyone internally/externally sends emails marked as private to that shared mailbox they do not appear in the inbox. You just see an unread number next to the inbox.



If this was a normal mailbox then all you would need to do is to log into the mailbox and delegate permissions for the shared mailbox to the users who need access to the private emails. In a shared mailboxes the user accounts are marked as disabled so this is not possible.

The way round this problem is:

1) Convert the mailbox to a user mailbox in the office 365


Login as Admin on the Office 365 portal > Select Exchange > Mailboxes > Shared Mailboxes > Select the mailbox > Select convert under convert to regular mailbox

This will bring up the message below. Click OK.



2) Assign a licence and reset the user’s passwords


Login as Admin on the Office 365 portal >Select users > Active Users > Search for the mailbox > Select reset Password and assign Licence on the right hand side


3) Log into the web portal with the temporary password created in step 2 above and reset with a password of your choice


4)  Create a new outlook profile using this mailboxes details and log into outlook.


5)  Assign permissions to the groups/users that need to have access to the private emails


Outlook > File > Accounts Settings > Delegate Access > Add > Select the users/distribution groups > Assign the relevant permissions you require and make sure you select Delegate can see my private emails.



6)  You can then remove the office 365 licence and convert back to a shared mailbox in the admin portal.


Users will now be able to see the privat emails sent to the shared mailbox.

Read More