Outlook Anywhere (RPC Proxy) Windows 2008 / Exchange 2007

In short, RPC Proxy, and IPv6 on Windows server 2008 has some “issues”.

This only occurs when you have Exchange installed on Windows 2008, not Windows 2003.
This also only applies to a "all roles installed on same server”. For my situation, this was a single exchange server installation.

The rpc proxy component is not compatible with IPv6, and even if you have it disabled (uncheck the ipv6 on the nic settings), it still uses the loopback component.

From the msexchange.org team, we find this:

If you’re in a single-server scenario where the RPCProxy and Mailbox are on the same machine, then the above does not work since the loopback interface still uses IPv6. In this case, you need to make the following changes in the system32\drivers\etc\hosts file:

  1. Comment out the line ":::1    localhost"
  2. Add the following two lines:
       <IPv4 address>    <hostname of the computer>
       <IPv4 address>    <FQDN of the computer>

When I tried the “rpcping” command (see the above link for how to), on port 6004, it gave me an error of Exception 1722 Port 6001 and 6002 worked ok. It is normal for the command to ask you passwords twice, and you can’t mess up and use the backspace key. You have to type it correct both times.

Also I noticed that the rpc proxy ports were wrong in the registry. The Valid Ports entry  was set to servername:593;servername:49152-65535 instead of
servername:6001-6002;servername:6004;servername.domain.ad:6001-6002;servername.domain.ad:6004
Honestly, I don’t know if those registry settings were bad or not, but I changed them to 6001-6002 and 6004.

I also tried uninstalling rpc over http, reboot server, and reinstalling rpc over http, but that did not fix it.

There is a good article related to this also at Exchange Genie.

And to clarify, I do have Exchange 2007, sp1, with rollup 5 installed. And Windows 2008 with SP1.

Advertisements

Finalizing the DC upgrade & Summary of Lessons #1 – #6

We migrated the file and print services to a new domain controller.

We used several tools like print migrator 3.1 and found out it can be used to back up / restore printers too, that makes it a good tool to have in the event you need to perform a custom disaster recovery. You hopefully downloaded and tried the 30 day eval of Beyond Compare. It makes syncing my laptop to my external usb drive a snap.

The last thing we have to do is move the FSMO roles to the new server, then decommission the old server. I’ll tell you up front, the old server will become a second domain controller and also a dns server. An interesting side note of smb edition, I was told that once you transfer the roles, you have 30 days to decommission the  server.

Moving the fsmo roles is easy, launch the correct mmc snapin, and connect to the target server, select the roles, click transfer.
http://support.microsoft.com/kb/324801

I would wipe the old server as cleanly as I was able to (restripe raid), install a fresh copy of windows 2003. Install the dns service first, then Dcpromo it to a domain controller. By installing dns first, it makes it easier to setup. I would use the old ip address, as there may be devices that talk to it for dns.

I would also install WINS on both servers and make them push/pull partners with each other. I would  rather have the clients ask a wins server than broadcast the question. It a quite efficient lookup server. Propriety and now antiquated, but efficient.

I did not cover the installation of a new exchange server. We will start that next.

Remember the client had one server, sbs03, it was the DC and the Exchange server. (Windows small business server 2003 and Exchange standard)

The final installation has two dcs, and one Exchange 2007 server. A total of three servers. All the servers will be running windows 2003 R2 edition. For clarity, I have x32 edtion on both dcs and x64 on exchange.

For clarity, we will call these servers dca, dcb, and exa.

image

RPC Proxy problems Windows 2008 / Exchange 2007

In short, RPC Proxy, and IPv6 on Windows server 2008 has some “issues”.

This only occurs when you have Exchange installed on Windows 2008, not Windows 2003.
This also only applies to a "all roles installed on same server”. For my situation, this was a single exchange server installation.

The rpc proxy component is not compatible with IPv6, and even if you have it disabled (uncheck the ipv6 on the nic settings), it still uses the loopback component.

From the msexchange.org team, we find this:

If you’re in a single-server scenario where the RPCProxy and Mailbox are on the same machine, then the above does not work since the loopback interface still uses IPv6. In this case, you need to make the following changes in the system32\drivers\etc\hosts file:

  1. Comment out the line ":::1    localhost"
  2. Add the following two lines:
       <IPv4 address>    <hostname of the computer>
       <IPv4 address>    <FQDN of the computer>

When I tried the “rpcping” command (see the above link for how to), on port 6004, it gave me an error of Exception 1722 Port 6001 and 6002 worked ok. It is normal for the command to ask you passwords twice, and you can’t mess up and use the backspace key. You have to type it correct both times.

Also I noticed that the rpc proxy ports were wrong in the registry. The Valid Ports entry  was set to servername:593;servername:49152-65535 instead of
servername:6001-6002;servername:6004;servername.domain.ad:6001-6002;servername.domain.ad:6004
Honestly, I don’t know if those registry settings were bad or not, but I changed them to 6001-6002 and 6004.

I also tried uninstalling rpc over http, reboot server, and reinstalling rpc over http, but that did not fix it.

There is a good article related to this also at Exchange Genie.

And to clarify, I do have Exchange 2007, sp1, with rollup 5 installed. And Windows 2008 with SP1.

Finalizing the DC upgrade & Summary of Lessons #1 – #6

We migrated the file and print services to a new domain controller.

We used several tools like print migrator 3.1 and found out it can be used to back up / restore printers too, that makes it a good tool to have in the event you need to perform a custom disaster recovery. You hopefully downloaded and tried the 30 day eval of Beyond Compare. It makes syncing my laptop to my external usb drive a snap.

The last thing we have to do is move the FSMO roles to the new server, then decommission the old server. I’ll tell you up front, the old server will become a second domain controller and also a dns server. An interesting side note of smb edition, I was told that once you transfer the roles, you have 30 days to decommission the  server.

Moving the fsmo roles is easy, launch the correct mmc snapin, and connect to the target server, select the roles, click transfer.
http://support.microsoft.com/kb/324801

I would wipe the old server as cleanly as I was able to (restripe raid), install a fresh copy of windows 2003. Install the dns service first, then Dcpromo it to a domain controller. By installing dns first, it makes it easier to setup. I would use the old ip address, as there may be devices that talk to it for dns.

I would also install WINS on both servers and make them push/pull partners with each other. I would  rather have the clients ask a wins server than broadcast the question. It a quite efficient lookup server. Propriety and now antiquated, but efficient.

I did not cover the installation of a new exchange server. We will start that next.

Remember the client had one server, sbs03, it was the DC and the Exchange server. (Windows small business server 2003 and Exchange standard)

The final installation has two dcs, and one Exchange 2007 server. A total of three servers. All the servers will be running windows 2003 R2 edition. For clarity, I have x32 edtion on both dcs and x64 on exchange.

For clarity, we will call these servers dca, dcb, and exa.

image

Moving the printers at the client side, Lesson #6

 

There is a vb script I found on the Internets, it’s very handy.

You run this against your users, upon logon, and you can run it multiple times (after the first time it doesn’t change anything). It looks in the registry on the workstation and finds the mapped printers, parses it, and changes the old name to the new name. It’s important when migrating printers to not change the name of the shared printer, otherwise this won’t work.  It’s a silent script, no popups.

I called my file pmigrate.vbs, and you can run it from group policy login script, or from a batch file with this line“cscript.exe \\domain.local\netlogon\pmigrate.vbs” Hint: Use the FQDN of active directory, and copy the vb script into the netlogon share.

I found other scripts, some that remove and reinstall printers, but that takes a long time. What is nice about this script is that it runs silent and it works flawlessly. After a while, a couple of day, you disable the running of it.

Option Explicit
Dim from_sv, to_sv, PrinterPath, PrinterName, DefaultPrinterName, DefaultPrinter
Dim DefaultPrinterServer, SetDefault, key
Dim spoint, Loop_Counter
Dim WshNet, WshShell
Dim WS_Printers
DefaultPrinterName = ""
spoint = 0
SetDefault = 0
set WshShell = CreateObject("WScript.shell")

from_sv = \\old ‘This should be the name of the old server.
to_sv = \\new ‘This should be the name of your new server.

‘Just incase their are no printers and therefore no default printer set
‘ this will prevent the script form erroring out.
On Error Resume Next
key = "HKCU\Software\Microsoft\Windows NT\CurrentVersion\Windows\Device"
DefaultPrinter = LCase(WshShell.RegRead (key))
If Err.Number <> 0 Then
DefaultPrinterName = ""
else
‘If the registry read was successful then parse out the printer name so we can
‘ compare it with each printer later and reset the correct default printer
‘ if one of them matches this one read from the registry.
spoint = instr(3,DefaultPrinter,"\")+1
DefaultPrinterServer = left(DefaultPrinter,spoint-2)
if DefaultPrinterServer = from_sv then
DefaultPrinterName = mid(DefaultPrinter,spoint,len(DefaultPrinter)-spoint+1)
end if
end if
Set WshNet = CreateObject("WScript.Network")
Set WS_Printers = WshNet.EnumPrinterConnections
‘You have to step by 2 because only the even numbers will be the print queue’s
‘ server and share name. The odd numbers are the printer names.
For Loop_Counter = 0 To WS_Printers.Count – 1 Step 2
‘Remember the + 1 is to get the full path ie.. \\your_server\your_printer.
PrinterPath = lcase(WS_Printers(Loop_Counter + 1))
‘We only want to work with the network printers that are mapped to the original
‘ server, so we check for "\\Your_server".
if LEFT(PrinterPath,len(from_sv)) = from_sv then
‘Now we need to parse the PrinterPath to get rhe Printer Name.
spoint = instr(3,PrinterPath,"\")+1
PrinterName = mid(PrinterPath,spoint,len(PrinterPath)-spoint+1)
‘Now remove the old printer connection.
WshNet.RemovePrinterConnection from_sv+"\"+PrinterName
‘and then create the new connection.
WshNet.AddWindowsPrinterConnection to_sv+"\"+PrinterName
‘If this printer matches the default printer that we got from the registry then
‘ set it to be the default printer.
if DefaultPrinterName = PrinterName then
WshNet.SetDefaultPrinter to_sv+"\"+PrinterName
end if
end if
Next
Set WS_Printers = Nothing
Set WshNet = Nothing
Set WshShell = Nothing

Migrating Printers made easy, Lesson #5

Moving printers from one server to another can be a long tedious process if you do it manually.

If you use Print Migrator 3.1, it’s easy. Download the file from the link, it’s the actual program. No install needed. Yep, it’s only 211k.

Step 1: image

Backup the current printers.

It dumps everything to a cab file you specify, i just called my printers.cab

image

 

Then it runs and runs and runs, scrolling files pass your eyes…..

image

Finally, you have a cab file.

In my case I had 12 printers, that made a 95 Meg file.

image

Then you copy that cab file and the print migration file from the source server (old) to the target server (new)

image

(i just put it all on the desktop for easy moving)

On the target server, you rerun the application, but choose restore. Pick the cab file you copied over, and fill in the field at the bottom of the box with the new server’s name. “\\newserver”

Then click open. It restores everything identical… it creates the necessary tcp/ip ports, drivers, names, shared name, everything….

image

This tool would be a good mechanism for disaster recovery of a server. I’m not sure if the system state restores all the printers and drivers this nicely. I don’t think it does.

So having this cab file backed up would be an ace in your pocket if you ever had to restore the server.

Migrating users to new Shared Folders, Lesson #4

It is important to understand that migrating the data and moving the users is broken down into three major steps:

1) Move the data initially, verify security rights moved over, test applications moved the new drive letter.
2) The night of cutover, perform a delta move. This means moving just the files that have changed or have been created on old production side. Beyond Compare is excellent for this (and many other things)
3) Change drive mappings (logon scripts) and remove the old shares. I insist on removing old shares so that users can’t get to the old data. You never ever want to find yourself with most users migrated, but some users still updating info on the old server.

In this lesson, we identify the logon scripts used by the end users, and change the drive mappings from the old server share to the new server share.

Some logon scripts are assigned on the user account. This is the old NT 4.0 way before group policy existed, and is seen on the Profile Tab of the user.

image

If the path is not specified, like in the above example, it implies the NETLOGON share on any domain controller. This entry is typically populated with a batch file (.bat)

 

To provide more flexibility, you can use group policy to assign logon scripts to users. In fact, you can assign logout scripts too, but it seems rare to be used. Group policy also allows you to assign “logon” scripts to computer ojbects. These are called Startup and Shutdown scripts, and as you probably guessed, they run on startup of the workstation before anyone logs on, and when the workstation shuts down.

This is where you should use the Group Policy Management utility to browse group policy objects and look for scripts that might be assigned. I have found that most people (admins) drop the scripts in the NETLOGON share and point to them in group policy.

The one thing nice about group policy is that it supports .vbs, .exe, and a wide range of other extensions.

For this client example, looking inside the default small business server logon script (SBS_LOGIN_SCRIPT.bat) reveals the following code:

cscript.exe \\activedirectorydomain.local\netlogon\logon.vbs

Interesting… in this case, the batch file runs a vb script.

Take note here that the unc path does not reference server but instead uses the active directory domain name. That way the client uses the current domain controller that it’s authenticating off of, not a specific one.

Inside the logon.vbs file we see this snipit of code:

    DriveMapper "H:","\\s1\home\" & fuser
    DriveMapper "P:","\\s1\GroupShare"
   

It should be obvious that you change the “s1” from the old server’s name to the new server’s  name. This is not the place to endulge in all the ways to map drives, and make logon scripts. We can cover that in another lesson.

The BIGGEST problem you are going to run into is PERSISTANT Drive mappings. A persistant drive mapping is one that is tied to the profile, when you map a drive and check the “Reconnect at logon” using explorer as seen here:

image

 

If the logon script was just a batch file that used the command: net use k: \\server\share, the user would get a popup saying something to the effect “Do you want to map to the new server, you have this drive mapped to the old server”. Most people say no to such changes, but that would be incorrect. Now the users is screwed, the old shares are removed, but the user said “no” to re-mapping the drive letters, so now the user has no drive mappings. Uggg..

If you modify the batch file and perform a net use k: /delete for each drive letter, then the user won’t get questions like that. Again, this problem only exists when users have persistent drive mappings.