Posts Tagged ‘Microsoft’

Hello again, it’s been a while, but this little nugget of information couldn’t wait, I want to keep it somewhere I can get to it quickly again!

Having performed many migrations between servers operating systems over the years, DHCP has always been a pain. When moving between differing versions of Windows, the backup/restore process doesn’t work, especially when you add in the change between x86 and x64. Well, there is an easier way which I’ve stumbled across today:

Install the DHCP Server role on the new 2012 Server, but don’t Authorize it.
On the Windows 2003 DHCP Server, open a command prompt and type: netsh dhcp server export C:\dhcp.txt all
Copy the file to the new 2012 Server.
On the new 2012 server, open a command prompt and type: netsh dhcp server import C:\dhcp.txt all
Open the DHCP console on the new server and authorize the server with Active Directory.
Stop the DHCP service on the old server, and disable it.

Now that’s much easier than manually re-creating a DHCP scope right?!

Apr 19

UPDATE: Checked with Exchange 2010, and this also resolves the issue.

Today I was dealing with a customer who was receiving errors in Outlook for autodiscover each time they opened Outlook. This was all after they’d changed their domain name.

I’d run a script I use to alter all of the host names, to check that they were all correct and then spent considerable time hunting around Exchange for this incorrect setting, and eventually found it.

It’s in the OutlookAnywhere settings, rather than in all of the other URL’s my other script alters. Usually, this URL doesn’t change, and so I’d missed it, but as they’d changed their domain name, this also needed alteration.

So, if you get SSL mismatch errors, and you think you’ve changed all of the necessary URL’s, check this one:

get-outlookanywhere | select Identity, ExternalHostName

if the External Host Name is incorrect, then adjust it with this:

get-outlookanywhere | set-outlookanywhere -externalhostname ""

This certainly works with Exchange 2007, I’ve not yet checked it on Exchange 2010, but believe it’s the same cmdlets.

I’ll write up a full blog post this weekend with a list of all of the places that need to be changed, so that it’s all in one place.

I’ve had a need to reset password’s for accounts on an automated basis more so recently than before, so not knowing where to start, I took a look around the internet and found some pieces of code here and there that would start to fulfill my needs.

Basically, I was setting up an 802.11x authenticated wireless network, and had a requirement to automate the password change of a RADIUS authenticated Guest account that was sat in a locked down OU in the domain. This then needed to be random, secure and e-mailed to a public folder so that the employees could give their guests access to the guest network. The script just needs to be added to a scheduled task to run monthly. So I eventually ended up with this:

import-module activedirectory

[int] $len = 12
[string] $chars = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789"
$bytes = new-object "System.Byte[]" $len
$rng = new-object System.Security.Cryptography.RNGCryptoServiceProvider
$result = ""
for( $i=0; $i -lt $len; $i++ )
$result += $chars[ $bytes[$i] % $chars.Length ] 

$securestring = ConvertTo-securestring $result -asplaintext -force

get-aduser "GuestUserName" | set-adaccountpassword -newpassword $securestring

$month= get-date -format MMMM

###Sets the mail values
$FromAddress = ""
$ToAddress = ""
$MessageSubject = "New Wireless Guest Details for $month"
$MessageBody = "Username: GuestUserName          Password: $result"
$SendingServer = ""

###Create the mail message and add the statistics text file as an attachment
$SMTPMessage = New-Object System.Net.Mail.MailMessage $FromAddress, $ToAddress, $MessageSubject, $MessageBody

###Send the message
$SMTPClient = New-Object System.Net.Mail.SMTPClient $SendingServer

In short:

Line 3: Specifies the number of characters in the generated password.
Line 4: The characters that can be used to generate the password.
Line 17: Reset’s the password on the AD account.
Line 19: Generates the month in long format to add to the e-mail Subject.
Line 22-26: Variables used for sending the e-mail.
Line 29: Generates the e-mail.
Lines 32 & 33: Sends the e-mail.

This morning I’ve been troubleshooting an Exchange public folder related issue that had me baffled for a little while.

Users could send e-mails to a public folder internally, but any external e-mails wouldn’t arrive in the folder. After running through message tracking I found the following error in the tracking logs:

550 5.2.0 STOREDRV.Deliver: The Microsoft Exchange Information Store service reported an error. The following information should help identify the cause of this error: “MapiExceptionNotAuthorized:”…

Knowing that internal users could e-mail the public folder, and knowing that the e-mails were reaching the Exchange server meant that I had to be dealing with a permissions based issue. When I looked at the public folder’s MAPI permissions using Powershell (get-publicfolderclientpermission is the cmdlet for that one) I could see that the folder was set to “Anonymous: None”. This means that anonymous senders don’t have rights to create a new item in the public folder, and so the 550 5.2.0 message is logged.

To get around this issue, you need to add at least the “CreateItems” access right for the Anonymous user. You can do this within Outlook looking at the permissions, or, in PowerShell as follows:

add-publicfolderclientpermission -identity "\PathTo\PublicFolder" -accessright createitems

To check this afterwards you can perform the following script:

get-publicfolderclientpermission -identity "\PathTo\PublicFolder" | where {$_.User -match "Anonymous"} | fl

Having some sites recently migrating from older SBS platforms to the latest 2011 release I found a need for a script to alter the login script settings for all users.

Whilst these days I’m primarily setting login scripts via Group Policy Objects there’s still a need to clean-up and remove the login script path from the user objects in Active Directory.

All of the below scripts need you to run this either on your Domain Controller, or via a machine with the Remote Server Admin Tools (RSAT) installed.

This little 2 liner will remove the currently configured script path for all users:

import-module activedirectory
get-aduser -filter * | set-aduser -scriptpath $null

This one will remove it dependant on user name (which you’ll input within PowerShell):

$username = read-host
import-module activedirectory
get-aduser $username | set-aduser -scriptpath $null

Finally, if you want to change the login script path, you’ll need to replace $null on the last line as per this example:

$username = read-host
import-module activedirectory
get-aduser $username | set-aduser -scriptpath '\\ServerName\Netlogon\script.vbs'

Over the last several years I’ve come across all sorts of issues connecting mobile phones to Exchange servers for syncing purposes… These have ranged in fixes for Exchange 2003 and needing to create an exchange-oma virtual directory, with some registry key changes, to fixing security problems within AD to resolve the issues.

In the past 6 months or so, I’ve been using this site to test these configurations (it saves messing around with your phone, or Windows Phone simulators):

This is the Exchange Remote Connectivity Analyser, and it works miracles!

It’ll test Autodiscover for you… as well as then trying to sync (with the account details you provide) with your mailbox (change the password before and after!). It then gives detailed steps and error messages (as well as links pointing to the usual causes of the problem) which can be used to troubleshoot further.

Sometimes it’ll complain about public certificates (usually if there is an intermediate CA in the certificate path), but if this is the case, just tick the “Ignore SSL Errors” check box, and it’ll happily run the test and only give you a warning instead of an error.

This site has helped me so many times before, and is extremely useful for troubleshooting… I always make this my first port of call should I have any Outlook Anywhere/ActiveSync errors.

I hope you find it as useful as I do!

%d bloggers like this: