Posts Tagged ‘communications’

Companies. Make VPN Easy For Yourselves…….

Tuesday, March 29th, 2011

So I come to work for yet *another* company who have a 192.168.0.0/24 network on their LAN. It’s not that it’s a bad idea as such, but history had made me come to realise it can cause problems later on. How ?

Hint: most domestic vendors of home network equipment (be they switches, routers or something with ADSL built into them) tend to use either 192.168.0.0 /24, 192.168.1.0/24 or 192.168.254.0/24

Yup, if you have a home network, chances are that it and all your home devices are on ip addresses 192.168.0.something, or a 192.168.1.something, with a network mask of 255.255.255.0.

If you create a 192.168.0.0 or 192.168.1.0 network in your office environment and then try to connect to the office VPN from your home LAN, these identical networks are likely to clash. The communication kit involved cannot deal with there being x2 identical 192.168.x.x networks in x2 different locations at the same time. As result, stuff may not work correctly. For example, if I connect to th work LAN from home, once the VPN connection is established, I cannot connect to anything on my home network until I disconnect.

Admittedly I work in IT and can work around or put fixes in place. But imagine if I was a co-worker from say marketing, or sales, or, *gasp horror*, someone from senior management. I’m trying to connect to the office from home, but it not going according to the instructions you gave me because we both have a 192.168.1.0 network !

You can imagine the long and frustrating support call(s) that ensue with them trying to vaguely convey to you their setup and you gently smashing a fork into your forehead to try and keep from going insane.

The long term work around is this. If you absolutely must have /24 networks in the office (/24 is a nice size network and very easy to calculate in your head) then use anything other than 192.168. with a 255.255.255.0 network mask. What you use doesn’t matter. As long as you avoid 192.168.x.x, you will reduce the possibility of clashing with some home user LAN over a VPN connection at a later date.

more than x1 192.168.x.x network ?!?

Where Did Everybody Go ?……

Friday, July 17th, 2009

When creating dynamic distribution groups (DDG) on Exchange server 2007 (distribution lists (DL) where the members are derived from an ldap query) you need to specify the active directory container where the query is to be applied !!

Failure to specify this will result in the query scope being set to the default ‘domainname/users’ container (not a problem if this is where your users happen to be, mine do not !!). The problem was that the power shell command to get the members of a DDG was working fine for me, but the exchange management console was not (the console was right).

I created a ‘test’ DDG and set it to include all users who had a mailbox. I then sent it an email and……nothing happened. I used message tracking to find where my message was going and saw

EventID : Expand, RecipientCount : 0   Since there are no recipients, the Expand Event within the Routing task was not followed by a transfer or delivery

When exchange was expanding the DDG to get the members there were none :o(

It was around this time I spotted an available parameter for DDG, -RecipientContainer. The recipient container was currently set to ‘domainname/users’ which is not where my user objects are located, they are in ‘domainname/our stuff/user/<dept>’ where each <dept> is a departmental subfolder (allows me a lot of control for group policy objects !).

I adjusted the DDG –recipientcontainer to ‘domainname/our stuff’ and presto, the list bursts into action and everyone gets an email. The ldap query seems to be recursive as all users in all sub containers were affected.

So for exchange DDG’s it not just what you make, but where you point it too that matter :oO

msexch