I’ve been banging my head against a brick wall recently with what should be a straightforward task.

I look after an SBS 2008 install and we are preparing to rationalise the email setup in the very near future by using Exchange 2007 that comes as part of SBS 2008

In preparation for that switchover I needed to create a shared mailbox for the “Admin” team. However, in SBS2008/Ex2k7 you can’t create a shared mailbox through the GUI’s, it can only be done by the Exchange Management shell (aka Powershell).

Not too much trouble I thought as I found a Powershell example, so I prepared my command:

New-Mailbox -Name:'Admin' -OrganizationalUnit:'lbc.local/Exchange resources' -Database:'Mailbox Database' -UserPrincipalName:'[email protected]' -Shared

But, this command kept failing: New-Mailbox : Active Directory operation failed on LBCSRV1.lbc.local. This error is not retriable. Additional information: Access is denied.

Active directory response: 00000005: SecErr: DSID-03152492, problem 4003 (INSUFF_ACCESS_RIGHTS), data 0At line:1 char:12+ New-Mailbox

I was using the SBS / Exchange administrator account, and doing this command on the server itself. After some searching I found a few posts that were experiencing the same problem but no real solutions.

Then it hit me! I tried opening the Exchange Management Shell as Administrator (right-click – Run As Administrator) ….ran the command again and hey-presto…..one shared mailbox created!!! Woooohooo!!

“I will tame SBS…I will tame SBS” 🙂

Two previous comments I received when my site was running Drupal:

Sabelo (not verified) – Tue, 17/08/2010 – 10:55

Thanks for your post it has saved me!! I have been battling with this error for solong and it never occured to me to do such a simple yet very important task. Thanks a lot once again.

David (not verified) – Wed, 02/05/2012 – 16:07

Legend, thanks for this. First result in Google and it fixed it.

I recently ran into issues with a Windows Sharepoint 2010 environment that is load-balanced by Cisco ACE modules. 

I’m no Sharepoint expert so if I get the WSS terminology slightly wrong – you’ll know why!

Basically the issues presented themselves in the following ways:

1. A Sharepoint site had some sort of webpart that enabled “live” view of Excel spreadsheets within the browser.

When you first visited the page, everything was fine and the spreadsheet loaded successfully, however upon navigating away to a different page, any subsequent requests were either met with a browser dialog box stating that an error occurred finding the file, or an HTTP 503 Gateway error.

2. Miscellaneous authentication issues (HTTP 401 Unauthorised)

From an networking perspective, this was occurring across a number of resilient pairs of ACE’s.  All were set for session persistency using a named cookie that was inserted by the ACE.

Nothing unusual so far!

Where it got interesting was when doing some packet captures, and Fiddler HTTP traces.

In these I could see that the cookie the ACE was insterting was present within the browser session, and an additional cookie set by WSS for keeping the session authenticated.  I also noticed that were two other entries in the cookie, that to me, looked like random characters, but I concluded that these were inserted by the WSS server.

After some investigation, I determined that the HTTP header was larger than 4096 bytes – the extra entries that WSS was added were around 3400 bytes each (there were two! ).

It transpires that there is a default number of bytes that the ACE checks for a cookie in the HTTP header is 4096 bytes. If a cookie, HTTP header, or URL exceed this 4096 value, the ACE drops the packet and sends a RST to the client.

The solution for our environment was to increase this value to overcome the large HTTP header size containing the WSS inserted data.

Changes needed on the ACE:

parameter-map type http HTTP_MAP_HEADER_LENGTH
set header-maxparse-length 16384

This defines a greater value. You can also set the ACE to passthrough any oversize packets if you choose to.

Then you need to apply that parameter-map to a policy.

policy-map multi-match my-policy-name
class my-class-name
appl-parameter http advanced-options HTTP_MAP_HEADER_LENGTH

Hope this helps someone out. Any questions or feedback is welcome via the comments link below.

Wow – what a title!!

Hopefully this post will make things a bit clearer.

I have a Cisco 1721 router configured to be a VPN server for a few IPsec client PC’s. Currently the user authentication part is just being done with local users setup within the router config.

However we have Windows SBS 2008 internally providing Active Directory services, amongst other things.

So, my aim in this piece of work was to get the Cisco VPN using the AD accounts for client VPN user authentication.

There were two main parts to getting this working – the config on the Cisco router, and the configuration of NPS (Network Policy Service (formerly IAS) on Windows. In this post I will cover the Cisco side, and will try to put up some notes on the Windows side when I get home where I am able to grab some screenshots.

Config required for Cisco router

This is the trimmed down version of the statements I had to add/change. If you need to see full config for understanding, drop me a note.

aaa new-model
aaa authentication login default local
aaa authentication login sdm_vpn_xauth_ml_1 group radius local
aaa authorization exec default local
aaa authorization network sdm_vpn_group_ml_1 local
radius-server host 1.1.1.1 auth-port 1812 acct-port 1813 key 7 "removed"

Potential stumbling block

One snag I ran into was related to the VPN group authenticaion. During my config changes I applied the following line (remotely – DOH!!!) which killed the VPN completely.

aaa authorization network sdm_vpn_group_ml_1 radius local

The symptoms this presented was the VPN client would try to connect but fail almost immediately.

What I didn’t realise to start with was that this config statement was offloading the VPN group authentication part of the connection over to the Radius server, where I didn’t have any groups setup, as I was only looking to use Radius for the user authentication.

So by leaving removing the radius option with that statement, the Group authentication check is still done against the name/key within the crypto isakmp client configuration group section.

Hopefully this can be of use to someone else – feel free to add any comments/questions below.