Petergal's SBS Blog

Free MCP Voucher - Limited Time Only

Petergal — Tue, 12 Jun 2007 01:53:00 GMT

Please see http://ts2blogs.com/blogs/petergal/archive/2007/06/11/10521.aspx and http://ts2blogs.com/blogs/petergal/archive/2007/06/07/9394.aspx for more details.

Petergal

My active blog is located...

Petergal — Wed, 04 Apr 2007 06:10:00 GMT

at http://ts2blogs.com/blogs/petergal

Thanks!

Petergal

Goodbye CSS, Hello TS2

Petergal — Tue, 16 Jan 2007 18:00:00 GMT

After 8 years in Product Support at Microsoft (CSS, formerly PSS), I decided to make a career change. I am now part of the Microsoft Across America (MSAM) team as a TS2 Presenter. The time spent in CSS has been invaluable. I am thankful for the relationships that I have developed - including the members of the SBS support team, local partners in the DFW area via the DFW-SBS Users Group and with partners and MVP's around the world.

Special kudos go out to the SBS support team in Las Colinas. I consider Chris Puckett, Damian Leibaschoff, David Copeland, Douglas Boyd, Ed Walters, James Frederickson, Jeff Taylor, Jim Martin, John Bay, Justin Crosby, Mark Stanfill, Mike Lieser, Roderick White and Shawn Sullivan friends. Keep up the outstanding work! There are countless Microsoft customers that count on you for everything that you do.

My first day in my new position was Jan 15th. I traveled my first day on the job! We are delivering Launch Content mostly around Office 2007 and Vista. I shadowed Charles Van Heusen in New Orleans and Baton Rouge on the week of the 15th. The week of Jan 29th was in Boise and Salt Lake City with Fred Pullen. The week of Feb 5th was spent in Redmond for TechReady (that's where Microsoft pulls in it's field people and shows us the new stuff). The week of Feb 19th was with Stephen Demming in Baltimore and DC. Today I am in Chicago with Don Roessler. I will be flying solo in the April timeframe. Check your local listings for a show near you!

I am not sure what direction my blog will go. I will definitely keep up my relationships with these geeks so if there is something late breaking and technical - you will see it here! My initial thought is to have this be like an answer board for questions from events. So whenever I say "ummmm, I don't know what licenses are required if you have Exchange 2007 Enterprise in an "edge transport" role and Exchange 2003 as your mailbox server...", I plan to post the answer on my blog. Whatever the case may be, I hope that your visits to my blog prove to be valuable (mostly).

Petergal

Installing and Configuring the Windows Mobile Stand Alone Emulator w/MSFP Images

Petergal — Tue, 03 Oct 2006 03:09:00 GMT

As a follow-up to this post, here are the steps to download and install the “stand alone” device emulator and Windows Mobile 5.0 w/Mobile Security and Feature Pack (MSFP) images. Once the following steps are completed, you will have a PocketPC image, a SmartPhone image and a SmartPhone QVGA image. You can use the emulators to test ActiveSync over-the-air functionality against an SBS 2003/Exchange 2003 server. These steps are not intended to be used to test ActiveSync over-the-air functionality with an SBS2003/Exchange 2003 server on the same LAN as the emulator.

What files to download:

l From http://www.microsoft.com/downloads/details.aspx?FamilyId=C 62D54A5-183A-4A1E-A7E2-CC500ED1F19A&displaylang=en, download efp.msi and V1Emulator.zip.

l From http://www.microsoft.com/downloads/details.aspx?familyid=D C8332D6-565F-4A57-BE8C-1D4718D3AF65&displaylang=en, download netsvwrap.msi - the Virtual Machine Network Driver for Microsoft Device Emulator.

What to install:

l Launch netsvwrap.msi to install the Virtual Machine Network Services Driver. Follow the on-screen instructions.

l Extract the contents of V1Emulator.zip. Launch standalone_emulator_V1.exe to install the Windows Mobile 5.0 Emulator Manager. Follow the on-screen instructions.

l Double click on efp.msi to install the Windows Mobile 5.0 w/MSFP images. Follow the on-screen instructions.

After the install is complete, you can access the emulator(s) via: Start -> All Programs -> Microsoft Windows Mobile 5.0 MSFP Emulator Images.

The options to boot the emulators:

l Device / Coldboot – Starts the selected emulator from a cold state (similar to a hard reset)

l Device / Savestate – Restores the image from the last time the emulator was running assuming “Save State” was selected when the emulator was previously shut down or closed.

Configuring the emulator to connect to the LAN/Internet:

l Launch the emulator of your choice (I strongly recommend the PocketPC. It is much easier to navigate and it uses a touch screen).

l In the Emulator Manager, click File -> Configure…

l Click on the Network tab and place a check next to “Enable NE2000 PCMCIA network adapter to bind to:”. In the dropdown, your physical network card should be selected.

l Click OK.

l Soft reset the device via File -> Reset -> Soft

Getting the emulator on the LAN/Web from behind a proxy server (think ISA server):

l Tap Start -> Settings -> Connections -> Connections -> Set up my proxy server and place a check next to “This network connects to the Internet” and “This network uses a proxy server to connect to the Internet” and type in the local IP address of the proxy server.

l If the proxy server uses a non-standard port (something other than 80) like the default SBS install w/ISA2004 does, you will need to modify the port for the proxy server. Tap Advanced and then tap HTTP and edit the port accordingly.

l Click OK all the way out

l Launch Internet Explorer on the device and to go to http://mobile.msn.com

Getting the emulator on the internet through a standard NAT device (think the standard Linksys, DLink, etc. device):

l Launch the emulator

l Tap Start -> Settings -> Connections -> Connections -> Advanced -> Select Networks and change the top dropdown selection to “My Work Network”

l Click OK all the way out.

l Launch Internet Explorer on the device and to go to http://mobile.msn.com.

Enjoy!

Petergal

MobileAdmin and Small Business Server 2003 - Server Error in '/MobileAdmin' Application.

Petergal — Mon, 11 Sep 2006 21:24:00 GMT

With the popularity of the Windows Mobile 5.0 devices with the MSFP, more and more people are wanting to play with Remote Wipe using the MobileAdmin utility.

Remember to follow these steps (specifically uncheck Require SSL for the ExAdmin virtual directory in IIS) if you intend to use the MobileAdmin utility on your Small Business Server 2003 computer. If not, when you search for a user/mailbox you will get the following error:

Server Error in '/MobileAdmin' Application.
--------------------------------------------------------------------------------

The remote server returned an error: (403) Forbidden.
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

Exception Details: System.Net.WebException: The remote server returned an error: (403) Forbidden.

Source Error:

An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.

Stack Trace:

[WebException: The remote server returned an error: (403) Forbidden.]
   System.Net.HttpWebRequest.CheckFinalStatus() +680
   System.Net.HttpWebRequest.EndGetRequestStream(IAsyncResult asyncResult) +74
   System.Net.HttpWebRequest.GetRequestStream() +234
   Microsoft.Exchange.AirSync.Admin.Mailbox.propFindRequest(String deviceUri) +240
   Microsoft.Exchange.AirSync.Admin.Mailbox.getDevices() +194
   Microsoft.Exchange.AirSync.Admin.Devices.refreshDevicesTable() +135
   Microsoft.Exchange.AirSync.Admin.Devices.Page_Load(Object sender, EventArgs e) +190
   System.Web.UI.Control.OnLoad(EventArgs e) +67
   System.Web.UI.Control.LoadRecursive() +35
   System.Web.UI.Page.ProcessRequestMain() +750

--------------------------------------------------------------------------------
Version Information: Microsoft .NET Framework Version:1.1.4322.2300; ASP.NET Version:1.1.4322.2300

The IP address of your local network adapter does not exist in the Local Address Table (LAT) for ISA Server

Petergal — Fri, 08 Sep 2006 03:36:00 GMT

When running the Small Business Server Configure Email and Internet Connection Wizard, you might see the following error:

The IP address of your local network adapter does not exist in the Local Address Table (LAT) for ISA Server. You will need to either add the IP address to the LAT or change the IP address of the network adapter. For more information, see Small Business Server Help.

This issue is caused by an incorrect value for LANNIC in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SmallBusinessServer\

LANNIC is set when SBS is first installed. When SBS setup sees two network cards during the initial setup (first run of setup, prior to the Component Selection Screen where you choose Exchange, Fax, etc) it will ask "hey, which of these two NIC's is your internal NIC?". When you select the NIC, two things happen: First, the other NIC is disabled. Second, LANNIC is written to the registry with the GUID of the internal network card. If you then subsequently swap cables, you might run into problems running the CEICW.

To resolve this issue, HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SmallBusinessServer\LANNIC will have to be changed to reflect the actual GUID of the internal network adapter.

Here's what you do:

Open Regedit and navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces
Expand Interfaces, you should see several folders underneath - highlight each of them, looking for a value called IPAddress with the internal IP address of the server. You will need to determine which GUID (folder on the left with the really long weird number) is the actual internal network card. Again, the one with IPAddress of the internal network card is the one you want.
Right click on the GUID of the internal NIC on the left and choose "copy key name".
Open notepad and paste the key into notepad.
Now highlight the GUID in notepad (not the brackets, just the characters) and copy it.

For example, copy A7237F71-448E-4ED3-AE5E-2EF8976399B5 from HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{A7237F71-448E-4ED3-AE5E-2EF8976399B5}

Navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SmallBusinessServer and double click on LANNIC
Copy the value you copied from notepad into LANNIC and click OK
Re-run the Small Business Server Configure Email and Internet Connection Wizard.

This article has the same steps but the error is different. If you follow the instructions in the popup error when running the CEICW ("Alternatively, disable the DHCP service manually, and then configure your client computer IP address properties.") you get further in the wizard but are then presented with the "ISA LAT error".

Happy SBS'ing!

Petergal

Error 0x86000108 with a Treo 700W tyring to sync with Small Business Server 2003

Petergal — Tue, 18 Jul 2006 03:14:00 GMT

This call gets the "weird case of the week" award. One user cannot sync their Calendar items on their device. They have a Treo 700W. Emails sync fine, Contacts sync fine, only the Calendar fails. It would get to 100 of 109 and then fail with the following error on the device:

Result:

ActiveSync encountered a problem on the server.

Support code: 0x86000108

This certainly sounds like a corrupt calendar item in the users mailbox or something goofy with the customers cell carrier (Compression issues maybe?). So I fired up my Mobile 5.0 emulator and tested with the problem account (let's call him Justin). Well, it failed with the same error code on the emulator. So it does not appear to be device/carrier specific. So the next thing we did was to export the mailbox to a PST and import it back into Exchange (exporting to PST *should* remove <not export> corruption). After doing that it still failed! Hmmmmm....this sounds like a job for Nextags! Well, looking at Nextags logs is about one step better than getting cut with a rusty knife so I thought I would look around a bit more. In the system log I found several events similar to the following:

Event Type: Information
Event Source: Ntfs
Event Category: (2)
Event ID: 37
Date:  7/17/2006
Time:  6:38:25 PM
User:  Domain\Justin
Computer: SBS-Servername
Description:
A user hit their quota limit on volume C:.

Event Type: Information
Event Source: Ntfs
Event Category: (2)
Event ID: 36
Date:  7/17/2006
Time:  6:38:25 PM
User:  Domain\Justin
Computer: SBS-Servername
Description:
A user hit their quota threshold on volume C:.

I wondered if disk quota limits were causing this to fail. Note we have a public article on this event, it should be a Warning and not an Informational event! So as a test, I turned off quota limits for the user on the C drive (open My Computer, right click on the C drive and click Properties, then the Quota tab, then the Quota Entries button. Right click on the user and choose Properties and put the bullet next to "Do not limit disk usage" and hit OK). This worked!

The moral to this story: ALWAYS check event viewer!!

Petergal

"No network provider accepted the given network path" accessing shares across a WAN link

Petergal — Sat, 03 Jun 2006 02:30:00 GMT

Interesting call this week. It was really quick fix. Really quick for 2 reasons:

I know the default behavior of a "clean" install of SBS.
I ran into the same issue here at my machine at Microsoft (not SBS, actually on the Microsoft corporate network...you'll understand later).

Visio would really help in this description!

Site A
SBS2003 with a single NIC
10.0.0.2 is the IP
Multiple clients on the 10.0.0.x network

Site B
Several clients on the 10.0.1.x network

Site C
Several clients on the 10.0.2.x network

Here are the facts:

The server and clients on Site A cannot access shares on Site B or Site C.
The clients on Site B cannot access shares on Site C.
The clients on Site C cannot access shares on Site B.
Clients on Site B and Site C cannot access shares on client computers on Site A.
Clients on Site B and Site C can access shares on the server itself located in Site A.
All clients and server can access shares on their own site.
All clients and server can ping all other clients by both FQDN and IP.
Site A, Site B and Site C are all connected via dedicated T1 links.
All the clients were configured correctly regarding their default gateways and DNS settings.
All clients are joined to the SBS domain.

The error when trying to access shares was:
---------------------------
\\ClientComputer

No network provider accepted the given network path.
---------------------------
OK
---------------------------

Here's the solution: SBS configures via Group Policy the Windows Firewall on Windows XP SP2 machines. There are exceptions for File and Printer Sharing in the policy that lock down File and Printer Sharing access to the local subnet of the client. I edited the Windows Firewall Group Policy (Opened Group Policy Management, navigated to Forest -> Company.local -> Small Business Server Windows Firewall. Right clicked on Small Business Server Windows Firewall and clicked Edit. This brought up the Group Policy Object Editor for the Small Business Server Windows Firewall policy.) Navigated to Computer Configuration -> Administrative Templates -> Network -> Network Connections -> Windows Firewall -> Domain Profile. On the right, opened the properties for "Windows Firewall: Allow file and printer sharing exceptions". The default configuration for "Allow unsolicited incoming messages from: LocalSubnet". I changed this to the following: 10.0.0.0/24,10.0.1.0/24,10.0.2.0/24. I then did a "gpupdate /force" on a test client and was then able to access shares. A quick test on clients on the different subnets was successful as well. This policy does not apply to the SBS server itself, thus clients could access shares on the SBS box.

I had the same issue here on my machine on the Microsoft corporate network. I would share something out and would get complaints from some people saying "you NOOB, give me access" (or some other choice words). My computer's Windows Firewall is not managed via Group Policy. I had to edit the Windows Firewall configuration on my local machine to allow access from other subnets. Here's the location for the manual configuration on the client: Properties of the Local Area Connection -> Properties -> Advanced -> Settings -> Exceptions -> File and Printer Sharing -> Edit -> Change Scope -> Any computer.

Have a good weekend!

Petergal

80090308 "The token supplied to the function is not valid"

Petergal — Fri, 12 May 2006 22:52:00 GMT

The customer was getting the above error when clicking on Public Folders in Exchange System Manager. He was also getting the following error when running the Add Distribution Group wizard and selecting to create an "archive public folder":

---------------------------
Add Distribution Group Wizard
---------------------------
The wizard could not successfully configure this group. The following could not be completed:

- The Exchange public folder could not be created.

Do you want to keep this group?
---------------------------
Yes No
---------------------------

This article was followed without success. What we did to resolve it was to remove a value in Active Directory using ADSIEdit. We had to install the Windows 2003 Support Tools to get access to ADSIEdit. With the SBS 2003 media, the support tools are located in cd2\support\tools\suptools.msi. The attribute is msExchSecureBindings. The value is :443:.

Specifically,

Configuration >

Services >

Microsoft Exchange >

Domain Name >

Administrative Groups >

First Administrative Group >

Servers >

Servername >

Protocols >

HTTP >

1 >

Exadmin

We right clicked on Exadmin and clicked Properties. We scrolled down until we found msExchSecureBindings and clicked Edit. By default, the value was/is :443: - we clicked to highlight :443: and clicked Remove. It then showed <Not Set> for msExchSecureBindings. We then restarted the Microsoft Exchange System Attendant and then restarted the IISAdmin service.

For all you (us) geeks, here is the full "distinguishedName": CN=Exadmin,CN=1,CN=HTTP,CN=Protocols,CN=SERVER,CN=Servers,CN=first administrative group,CN=Administrative Groups,CN=COMPANY,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=company,DC=local

The root cause is because the certificate that was installed in IIS did not contain the "servername" in the "subject" field (you have to view the certificate and click the details tab to see this field).

Error 0x80830003 with ActiveSync and a Cingular 8125

Petergal — Mon, 08 May 2006 23:10:00 GMT

Scenario:

SBS2003
4 devices - all sync fine

2 Cingular 2125 SmartPhones
2 Cingular 8125 PocketPC Phones

Install Exchange 2003 Service Pack 2

2 Cingular 2125 SmartPhones still sync
2 Cingular 8125 PocketPC Phones error with 0x80830003

Solution (workaround):
On the 8125 device(s), click start -> settings -> connections -> connections. Cingular appears to have renamed “My ISP” to “MEdia Net”. Click “Edit My Proxy Server” under “MEdia Net” and UNCHECK “This network uses a proxy server to connect to the internet”. By default it was set to “wireless.cingular.com”. Soft reset the device.

Note we believe this issue to be related to 0x8503001A (IIS compression settings) but has been unconfirmed.

Marbles in my server...

Petergal — Tue, 02 May 2006 02:56:00 GMT

That's what I thought the sound was! Upon further review, the hard drive was making that horrible noise. Server is dead, completely dead! Drive imploded on itself. Well, off to another "migration". Thank goodness for my replica domain controller. Seized the roles, deleted the Exchange objeccts out of AD, installed SBS on my workhorse Dell Precision 610 (Xeon 550), canelled the setup at the Windows portion, DCPromo'ed in, etc...etc...etc...

With the SBS2003 SP1 media, I still had 32 CRITICAL updates from Microsoft Update. Back up and running again.

Petergal

SBS2003 server cannot ping 2 clients on the local LAN

Petergal — Wed, 12 Apr 2006 20:46:00 GMT

Ok, simple stuff here. The call was:

1. SBS2003 with a single NIC (192.168.16.2)

2. Clients on the same network (192.168.16.x)

3. Clients on a different subnet (192.168.15.x)

4. The server cannot ping ONE client on the 16.x network and cannot ping ONE client on the 15.x network.

Ok, back to "IP Routing 101". So, we can safely assume whatever device that is connecting the two networks has the proper routing table because some of the clients from Network A could ping clients on Network B. My first thoughts were we have to have a goofy static route on either the server or on the two clients -or- the subnet mask is wrong on one of the computers. We did a "route print" from the one client on the 16.x network. No static routes for the 15.x network. While performing the same command on the other client the customer proclaimed "success". He turned off the Windows Firewall on the client!

Customer = 1

Petergal = 0

Sometimes it's the small stuff! Of course we don't want to leave the firewall off. Adding the appropriate exceptions was the final solution.

Petergal

SBS2003 Exchange spewing out 33,000 emails

Petergal — Tue, 11 Apr 2006 22:02:00 GMT

The way that "relay" can present itself can be very interesting. The customer reported that he was an "open relay" and followed http://support.microsoft.com/default.aspx?scid=kb;EN-US;324958
to "clean it up". After about a month, the problem came back. Interesting...

Using http://support.microsoft.com/default.aspx?scid=kb;EN-US;324958, a quick test determined he was not an open relay in the traditional sense of the term. The customer was using the Pop3 Connector to retrieve email. Another symptom was that the Pop3 Connector was not delivering email to the users. It would download it from the ISP but the mail would get stuck in C:\Program Files\Microsoft Windows Small Business Server\Networking\POP3\Incoming Mail. There were also about 1,300 emails in C:\Program Files\Microsoft Windows Small Business Server\Networking\POP3\Failed Mail. We opened one of the EML files in notepad and noticed the "TO:" contained about 500 recipients, one of which was for the local domain.

This was a clear indicator that the customer needed http://support.microsoft.com/?kbid=835734.

So...this was a great opportunity for the consultant to sell the customer on a managed solution because this problem SHOULD HAVE NEVER HAPPENED if the server was updated regularly. This fix was offered by Microsoft Update and is also included in SBS2003 Service Pack 1.

Petergal.

The rest of the story...the migration completed...(long post)

Petergal — Fri, 07 Apr 2006 15:28:00 GMT

Well, I have procrastinated long enough on wrapping up the migration story. Here it is...

----------------------------------------

I planned this process as much as I could, most went as planned, some oversights. Note that prior to my steps below, These steps were performed about a week prior (transferred the FSMO roles, exported the public certificate).

Here is what I did:

I copied my most recent SBS Backup file from a Windows XP machine back to the local SBS box on a separate partition. I did this in case I ran into a driver issue (the network cards). I could always restore the Windows directory to an alternate location, then point the hardware wizard to c:\restored\winnt\inf and it should pick up the drivers
Made sure my backup of the replica domain controller was successful
Uninstalled WSUS and deleted my WSUS policy. I did this because I just got a copy of SBS R2 which includes WSUS. I also needed the space on the server to copy the backup file local to the sbs box (step 2 above).
Opened Active Directory Users and Computers on the SBS Box and did a search for users with Exchange mailboxes, highlighted them all, right click, Exchange tasks, delete Exchange attributes. You can't uninstall Exchange if there are users who have mailboxes.
Went into Active Directory Sites and Services and did a Replicate Now for both connections
Ran the SBS integrated setup, chose to REMOVE Exchange
Rebooted the SBS box
Ran DCPromo on the SBS box and chose "remove" Active Directory
Got an error regarding "timeout" for the Netlogon service, continued...
Got a message stating that Active Directory was successfully removed and prompted for a reboot, rebooted Server.
While Server was rebooted, hopped over to Win2kdc and performed the following:
- Ran NTDSUTIL to see if the server was gone, it was. Just looking around…
- Went into Active Directory Sites and Services -> Sites -> Default-First-Site-Name -> Servers and right-clicked on Server and chose DELETE.
- Deleted all the Exchange attributes in Active Directory Users and Computers (click on View -> "Advanced Features". Under Company.Local, located and deleted Microsoft Exchange System Objects.
- Deleted Exchange attributes in Active Directory Sites and Services. Opened AD Sites and then clicked on Active Directory Sites and Services (win2kdc.company.local) and then clicked View -> "Show Services Node". Under Services, located and deleted Microsoft Exchange.
- Opened DNS on Win2kdc, removed server.company.local from the Nameservers tab on each of my DNS zones (both forward and reverse zones).
- Stepped though each zone and deleted any record for server.company.local and/or192.168.50.2.
- Rebooted Win2kdc for good measure.

At this point, I simply have a single domain controller (remember this domain controller is in Virtual Server on a WinXP Pro box) with no trace of Exchange installed.

Now off to install my clean install of SBS.

Booted the old box from the SBS media and kicked off the setup (the Windows portion)
Unplugged the network cable from the cable modem
Deleted the C partition, created new, format NTFS, off we go...
At this point, I started copying the other SBS CD's to my Windows XP workstation so I could complete the rest of the SBS setup across the network, not having to flip CD's.
Typed in the product key and then a servername and Administrator password. The servername I chose was "Apollo". Continued setup...
While SBS was installing, took a quick look around on Win2kdc. Checked Event Viewer and was presented with this error:

Event Type: Warning

Event Source: NETLOGON

Event Category: None

Event ID: 5781

User: N/A

Computer: WIN2KDC

Description: Dynamic registration or deletion of one or more DNS records associated with DNS domain 'DomainDnsZones.company.local.' failed. These records are used by other computers to locate this server as a domain controller (if the specified domain is an Active Directory domain) or as an LDAP server (if the specified domain is an application partition).

Possible causes of failure include:

TCP/IP properties of the network connections of this computer contain wrong IP address(es) of the preferred and alternate DNS servers
Specified preferred and alternate DNS servers are not running
DNS server(s) primary for the records to be registered is not running
Preferred or alternate DNS servers are configured with wrong root hints
Parent DNS zone contains incorrect delegation to the child zone authoritative for the DNS records that failed registration

USER ACTION

Fix possible misconfiguration(s) specified above and initiate registration or deletion of the DNS records by running 'nltest.exe /dsregdns' from the command prompt or by restarting Net Logon service. Nltest.exe is available in the Microsoft Windows Server Resource Kit CD.

Don't really care about that one!

SBS setup is continuing on fine...

The Windows 2003 portion of setup completed, statically assigned an IP address to the nic, pointed him to Win2kdc for DNS, enabled Remote Desktop, disabled the Windows Firewall on the nic and then did an RDP from the Windows XP workstation to Apollo.
I am now "joining SBS to an existing domain" per this article. Kicked off DCPromo. DCPromo completed and required a reboot. I rebooted and walked away...came back to a logon prompt and logged on. Walked away again and came back to the SBS desktop...the actual fully installed SBS desktop from earlier in this process! $(#*$*(#??? I have a hardware mirror...did the mirror break? So I started poking around on the "SBS" box. A quick inventory of the contents of the root of all the drives showed me that my Apollo install is actually on the E drive and the SBS install (Server) shows as on the C drive. Nice! What happened was that I accidentally installed to an IDE drive. All my partitions/drives are very close in size. No worries, clean install means clean install. Anyway, what to do next. The phone just rang...my house is for sale and it is going to be shown from 12:30 to 1:30 today! Now I have about 2 hours to get this thing back on track! When it rains, it pours! Oh, I wonder how Active Directory is responding to this Domain Controller being back on the network? Ok, so I unplugged the IDE drive and kicked off another setup. I deleted all partitions and created a single partition and setup continued. While setup was running, I hopped over to Win2kdc and ran through the NTDSUTIL article again and removed APOLLO from Active Directory Users and Computers and Active Directory Sites and Services (basically the same thing I did above for “Server” but this time for “Apollo”). I then stepped through DNS again on Win2kdc and deleted all references of APOLLO.
Apollo setup completed, rebooted and it is now just running Windows 2003 Server as a stand-alone server. I set the IP address to static, pointed him to Win2kdc for DNS and ran DCPromo (following this article again). It prompted for a reboot, which I did. This time when I booted up, it was to the right place. Now on with my plan.
I disabled the Windows Firewall on Apollo, turned on Remote Desktop and logged off. I then logged on via Remote Desktop from the Windows XP machine (did I mention that my server Apollo does not have a mouse?).
Once logged on, I installed DNS on Apollo, set Apollo to point to himself for DNS, waited for all the Active Directory Integrated DNS zones to show up on Apollo (about 30 seconds)
Made Apollo a Global Catalog server and rebooted Apollo. Apollo is now a "replica" DC in an existing domain. I am now waiting for the events to show that Apollo is successfully a Global Catalog server. Waiting...nothing. I go check to see if Apollo is set to be a Global Catalog server, he is not, checked the box again and rebooted Apollo again...now I have the event I am looking for:

Event Type: Information

Event Source: NTDS General

Event Category: Global Catalog

Event ID: 1869

Computer: APOLLO

Description: Active Directory has located a global catalog in the following site.

Global catalog:

\\apollo.company.local

Site:

Default-First-Site-Name

Even after seeing the event, I check replication manually. I create a user in Active Directory on Win2kdc and then check Active Directory on Apollo, there he is! I then delete the user in Active Directory on Apollo and check Active Directory on Win2kdc, he's gone. I then open up Group Policy Management on Apollo and change a simple policy (the Windows Firewall Policy, I set it to "disabled") and then opened up Group Policy Management on Win2kdc and the change was replicated. I then did a GPUPDATE /FORCE on one of my clients and waited for the SCECLI event 1704 that says "policies were applied successfully", no go. What gives? Well, back to my original configuration the SBS box was the DHCP server handing out addresses pointing to himself for DNS...that is now a problem because my clients are all DHCP clients. I set my box up to have a static DNS server pointing to Apollo and restarted NETLOGON on the client and did an ipconfig /flushdns on the client and then repeated the GPUPDATE /FORCE and the Windows Firewall Policy was gone (meaning I can turn off/on the Windows Firewall on the client)! This is good!
I then removed the "Global Catalog" setting on Win2kdc and then rebooted Win2kdc. The it's now 11:00 AM, about 30 minutes until I have to step away to get the house cleaned up for the 12:30 showing!! The phone rings, one of my "users" wants to know when email will be back up... <sigh>.
Now I transferred the FSMO roles to Apollo, forced replication and then kicked off the SBS setup on Apollo, acknowledged the warning about the DS Restore Mode password being synced with the Domain Administrator account, hit next, prompted for a CD, mapped a drive to the Windows XP box that has all the install files for SBS, pointed SBS setup across the network and setup continued...got to the component selection screen, accepted the defaults for what to install and where to install it and continued...left the house so it could be "shown". Back an hour later... The only hiccup was that the SBS setup barked for the Outlook CD, which I manually browsed to. Setup completed. Active Directory is intact, life is good. Now on with the the rest of the setup.
Installed Exchange 2003 SP2
Visited Windows Update, installed all critical updates...
Time to restore Exchange. I dismounted both the Public and Private stores, marked each to be "overwritten by a restore" and deleted the contents of c:\program files\exchsrvr\mdbdata and kicked off NTBackup. Chose the Information Store and hit go. It failed immediately and generated the following error in the Application Log:

Event Type: Error

Event Source: MSExchangeIS

Event Category: Exchange Backup Restore

Event ID: 9635

User: N/A

Computer: APOLLO

Description: Failed to find a database to restore to from the Microsoft Active Directory.

Storage Group specified on the backup media is 581cb7ee-5fec-4d93-8f71-dcfe55a73319.

Database specified on backup media is Mailbox Store (SERVER), error is 0xc7fe1f42.

Hmm…the storage group names do not match. New = Mailbox Store (Apollo), Old = Mailbox Store (Server). I renamed Mailbox Store (Apollo) to Mailbox Store (Server) in Exchange System Manager -> Servers -> First Storage Group -> Mailbox Store (Servername) and kicked off the restore again. This time it proceeded and completed successfully. This was an oversight regarding the default behavior of an Exchange install using the SBS integrated setup. I *could* have ran the Exchange setup manually from the SBS media and it would have prompted me for the site/org name. Exchange data has been restored (minus Public Folders, don’t have any data).

Now time for ISA2004. I browsed across the network and kicked off the ISA2004 install from the Premium Technologies CD, completed, ran CEICW, chose mail.company.com, completed.

Created a rule in ISA to accommodate DNS hosting <don’t host your own DNS>

Imported the original certificate into the local certificate store. Start -> Run -> MMC -> Personal -> Action -> All Tasks -> Import. Remember I exported the original certificate prior to the migration.

In ISA, changed the certificate from the new mail.company.com to the original certificate I just imported. This is done in ISA -> “Any SBS Web Publishing Rule” -> Properties -> Listener -> SBS Web Listener -> Properties -> Preferences -> Select.

What's left...tested mailflow from Hotmail and Microsoft to my domain, success. Ok, we look golden.

I checked my user that uses a SmartPhone. The SmartPhone freaked a couple of times, I deleted the settings and typed them back in on the device, works.

Now on to the RPC over HTTP computer. Here is where I discovered another error in my ways. I went to great lengths to ensure the certificate was the same so I would not have to go re-add the certificate to the RPC over HTP clients, what I forgot is that since I changed the servername from SERVER to APOLLO, they would all have to be touched anyway. My worst case I thought would be that I would delete and recreate the profile in Outlook. Oh well, live and learn. Deleted and recreated a new Outlook profile, works. I did this on my 2 RPC over HTTP clients.

For grins, I sent another email just to test and got a lovely NDR stating that the recipient’s mailbox was full! The default behavior of an SBS install is to limit the mailbox size of all the users to 200 MB. My mailbox is a GIG and another one is 700 MB. It was interesting that my original tests from Hotmail and Microsoft came through. I went to my account and the other account in Active Directory (properties of the user -> Exchange General -> Storage Limits and unchecked “Use mailbox store defaults”) and overrode the default limits. This could have been a MAJOR issue and COULD have resulted in data loss. Hey, did you get that email I sent??? Nope!

I then checked my daughter’s mailbox on her workstation. She was hanging out and looking over my shoulder while I was working through this process. She is getting mail about the Nigerian prince and his fortune as well as some choice emails about Viagra. This really pissed me off! I honestly had to explain the Nigerian thing to a 9 year old. Thank goodness she did not see the Viagra spam. I had not implemented any of the anti-spam features of Exchange. I implemented my settings again (IMF/Connection Filtering, etc) and then deleted the email out of her mailbox.

I then implemented the steps in this article to allow Microsoft Update to automatically update the signatures for the Intelligent Message Filter. A quick trip to Microsoft Update and “custom” presented me with the IMF updates which I installed.

Tried to browse the web from her Windows XP pro client, failed! “Cannot find server or DNS error”. On her computer, Internet Explorer is NOT set to use a proxy server and the ISA Firewall Client is installed. I noticed the Firewall Client was “banged” in her System Tray. She is running the ISA2000 Firewall Client. Doing an “update now” was successful and removed the “bang”. Trying to browse resulted in the same error and the Firewall Client “banged” out again. Remembering the default behavior of an ISA2004 “clean install” as opposed to an upgrade from ISA2000, “Allow non-encrypted Firewall client connections” is UNCHECKED on a clean install of ISA2004 and it is CHECKED on ISA2000 -> ISA2004 upgrades (on SBS anyway). In ISA -> Servername -> Configuration -> General -> Define Firewall Client Settings I CHECKED “Allow non-encrypted Firewall client connections” (my previous install was an SBS2000 -> SBS2003 upgrade thus the box was checked prior to the migration) and hit OK and then Apply. Now she can browse!

At this point, I think I am back to a good working server/network. It's about 5 in the afternoon. Not too proud of the way things went for this migration.

And now…the rest of the story…

Woke up on Sunday morning, had my cup of coffee and started the process over again! I basically did the same steps as before but chose Server as the SBS servername. No DCPromo down, no uninstall of Exchange. I transferred the FSMO roles, booted Apollo off the SBS media and started a fresh install. While this was running, I cleaned out Apollo from Active Directory using NTDSUTIL and manually deleting the Exchange objects from Active Directory Users and Computer as well as Active Directory Sites and Services. I started at 7:00 AM and was complete at around Noon. Much smoother experience. The majority of the time was the install itself. The only “unexpected” issue I ran into was the Anonymous Account’s password for IIS was out of sync with the password in Active Directory. By default, the anonymous account is called IUSR_Servername. In my case, IUSR_SERVER. The symptoms were: trying to browse Outlook Web Access from the server itself gave the NTLM popup logon – not the pretty OWA login page; providing the username/password resulted in a half-drawn OWA page (very similar to the issues resulting from Q831464 but I have SP2 for Exchange, so that’s not it). As a quick test, I tried to browse http://server/tsweb and got a 440 Login Timeout error. I use TSWeb all the time to test basic IIS connectivity. It is a website installed by default on SBS with Anonymous Access turned on. The 440 Login Timeout is usually the anonymous account password in IIS is out of sync with Active Directory.

Here is how I fixed that:

Open Active Directory -> Users -> IUSR_SERVER -> Right Click -> Reset Password

Open Internet Information Services Manager -> Servername -> Web Sites -> Right click Web Sites -> Properties -> Directory Security -> Edit for Authentication and Access Control -> typed in the password that I set in Active Directory in the Password field.

Click OK and then “select all” for Child Nodes.

Select All again for Child Nodes

Restarted the IISAdmin service

Wrapping up the migration, I made sure all the clients were pointing to Server for DNS. Login scripts are running and policies are being applied. Life is good again!

Here is a list of quick hits regarding this migration:

This may have seemed hard but it was really pretty easy.
Always test your solutions! Know your processes! I have walked many customers through each of the different aspects of a migration. Putting it all together can be unique for each scenario.
When migrating with this type of method, always test replication throughout the process. Replication should always be working.
I messed with the clients “during” the migration, which was not necessary. Replication between the servers is the key. Clients may freak during the migration. It is a waste to troubleshoot clients in the middle of the migration. Get the AD stuff migrated between the servers, get DNS right on the server(s)...then start messing with the clients.
Did I mention DNS? If DNS is wrong, Active Directory replication will be broken which will make the migration much more difficult
Have verified backups prior to starting any migration
Know the Exchange restore method that is specific to the migration scenario. PST files, Offline Backups, Online Backups…all of which present different challenges/requirements when restoring.
Did I mention DNS?
Did I mention testing replication?
It was painful for my RPC over HTTP user that had a 700 MB mailbox. She is accessing Exchange from 2 different computers with RPC over HTTP. It took a full 2 days to sync both Outlook clients! The user’s complaint was that “sent items” was not updated on each client (“Hey, I sent a mail from the office but when I go check “sent items” on my home computer, it does not show up…did it go out??”). I should have advised her to leave Outlook open when she left the office (or wherever) to allow it to do a full sync.
Get your antivirus/anti-spam solution installed and up-to-date prior to putting the server (or the server’s services, like SMTP) live on the internet.
Remember the default configuration settings of an SBS install and what you have “tweaked”. Mailbox limits in Exchange, IMF settings, IMF updates via Microsoft Update, Disk Quotas (defaults to 1 gb), ISA2004 setting changes, etc.

Have a good weekend!

Petergal

Stop 0x000000D1 DRIVER_IRQL_NOT_LESS_OR_EQUAL (8a400000, 00000002, 00000000, f77e00a9)

Petergal — Thu, 23 Mar 2006 18:22:00 GMT

I had a great call yesterday. Great meaning I was able to empower a customer to debug a memory dump so he could potentially resolve a STOP error in the future more quickly. Everyone wins in that scenario: end customer is back up and running quickly, consultant can go off and make more service calls to more customers and Microsoft wins because he does not have to call for support (we lose money on each call).

Here's the issue: Server is randomly rebooting about once every 4-5 days. No bluescreen, no memory.dmp. The behavior seemed like someone was simply pulling the plug on the server! Not good!!

Well, checking System Properties -> Advanced -> Settings for Startup and Recovery showed the server was set to "Small Memory Dump (64k)" under "Write debugging information" and to "Automatically restart". A quick search on the server revealed a mini-dump of 64k dated the time of the last "crash". What this tells me is that the server IS actually performing a bugcheck (Blue Screen of Death or BSOD) and rebooting but since it is only configured for a "Small Memory Dump", it dumps so quickly that the BSOD is never presented. So, we set the "Write debugging information" to "Kernel Memory Dump" and rebooted. Now we have to wait for the server to crash.

After several days, it did and we now have a Memory.dmp file. Here is the steps we performed to debug the memory dump:

Downloaded and installed the current "Debugging Tools for Windows 32-bit version" from http://www.microsoft.com/whdc/devtools/debugging/installx86.mspx, choose "typical".
Launch the debugger via Start -> All Programs -> Debugging Tools for Windows -> WinDbg
Set the symbol file path: File -> Symbol File Path. From http://www.microsoft.com/whdc/devtools/debugging/debugstart.mspx: For example, to download symbols to c:\websymbols, you would add the following to your symbol path: SRV*c:\websymbols*http://msdl.microsoft.com/download/symbols. I simply copied and pasted SRV*c:\websymbols*http://msdl.microsoft.com/download/symbols into the Symbol Search Path and then created a directory called "websymbols" on the root of the C drive. You don't have to create the folder, the debugger *should* create it for you when it connects.
I placed the check next to "Reload" and clicked OK.
Load the dump file: click File -> Open Crash Dump and browsed to the memory.dmp
Clicked Yes to "Save Information for Workspace"
Sit back and wait.
Take a quick look in c:\websymbols, you should see some stuff (symbols) appearing in this folder
After some time (one minute to 5 minutes, ymmv), the debugger will be done loading and you will see "0: kd>" in the small grey window at the bottom left of the screen.

Note the debugger does not *have* to be installed on the server itself. All you have to do is have local access to the dump file. You could copy the dump file to a Windows XP workstation and install the debugging tools on the workstation rather than the server.

Here's the output after loading the dump file (I did not run a single command). Around 80% of the calls we get (PSS SBS) regarding memory dumps are resolved by simply loading the dump in the debugger, as illustrated below.

Loading Dump File [C:\Documents and Settings\petergal\My Documents\MEMORY.DMP]
Kernel Summary Dump File: Only kernel address space is available

Symbol search path is: SRV*c:\websymbols*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows Server 2003 Kernel Version 3790 MP (2 procs) Free x86 compatible
Product: LanManNt, suite: SmallBusiness TerminalServer SmallBusinessRestricted SingleUserTS
Built by: 3790.srv03_gdr.050225-1827
Kernel base = 0x804de000 PsLoadedModuleList = 0x8057b6a8
Debug session time: Wed Mar 22 02:59:01.750 2006 (GMT-6)
System Uptime: 1 days 9:42:01.500
Loading Kernel Symbols
.............................................................................................................
Loading User Symbols
PEB is paged out (Peb.Ldr = 7ffdf00c). Type ".hh dbgerr001" for details
Loading unloaded module list
.....
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck D1, {8a400000, 2, 0, f77e00a9}

*** ERROR: Module load completed but symbols could not be loaded for CSTDI50.sys
Probably caused by : CSTDI50.sys ( CSTDI50+10a9 )

Followup: MachineOwner
---------

Notice the "Probably caused by: CSTDI50.sys" Ok, what the heck is that file? Find the file -> properties -> version -> who's file is this anyway? The file belongs to Colasoft. As soon as we determined who the file belongs to, it was determined that this software was installed last November and a quick scroll through Event Viewer showed the problem started around November. A quick search on the internet for CSTDI50.sys confirmed that Colasoft has a "known issue".

The action is to uninstall the Colasoft software.

With the steps above, you *should* be able to hopefully determine the cause of the crash!

To be really geeky, "!analyze -v" (without quotes) can be ran in the debugger to give additional (in this case, pretty useless as we already know the cause) information:

0: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If kernel debugger is available get stack backtrace.
Arguments:
Arg1: 8a400000, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: f77e00a9, address which referenced memory

Debugging Details:
------------------

READ_ADDRESS: 8a400000

CURRENT_IRQL: 2

FAULTING_IP:
CSTDI50+10a9
f77e00a9 f3a5 rep movsd

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0xD1

LAST_CONTROL_TRANSFER: from 804e2f58 to 80543ac9

STACK_TEXT:
b87be8b0 804e2f58 0000000a 8a400000 00000002 nt!KeBugCheckEx+0x19
b87be8b0 f77e00a9 0000000a 8a400000 00000002 nt!KiTrap0E+0x224
WARNING: Stack unwind information not available. Following frames may be wrong.
b87be94c f77e02d5 888c0630 887e30c8 01ed6000 CSTDI50+0x10a9
b87be974 f77e0747 884db750 8000089c 888b8200 CSTDI50+0x12d5
b87be990 f77e0c58 00000001 00000000 88b8cf68 CSTDI50+0x1747
b87be9bc f77e0ea3 00000001 00000000 88b8cf68 CSTDI50+0x1c58
b87bea08 804f0154 00000000 88b8cf68 018b81c8 CSTDI50+0x1ea3
b87bea38 ad82394a 88843288 88b8cfd8 f77dffdb nt!IopfCompleteRequest+0xa0
b87bea44 f77dffdb 8982b200 88b8cf68 88b8cfd8 tcpip!TCPDispatchInternalDeviceControl+0x134
b87beaa0 f77e10f1 8982b200 88b8cf68 f77e3e40 CSTDI50+0xfdb
b87beafc ad6b6851 884db750 b87beb84 00000004 CSTDI50+0x20f1
b87beb74 ad6b80c7 89924e40 8000089c 8000089c afd!AfdCreateConnection+0x195
b87beba0 ad6b80f7 898bfab0 8831f0e4 8831f008 afd!AfdAddFreeConnection+0x37
b87bebb4 ad6c5997 00000000 00012083 ad6c57f0 afd!AfdReplenishListenBacklog+0x13
b87bec30 ad6c0043 8831f008 89a27a60 804f0473 afd!AfdSuperAccept+0x1cf
b87bec3c 804f0473 89927030 8831f008 883175f0 afd!AfdDispatchDeviceControl+0x4f
b87bec4c 80585208 8831f0e4 897c0e90 8831f008 nt!IofCallDriver+0x3f
b87bec60 805860e6 89927030 8831f018 897c0e90 nt!IopSynchronousServiceTail+0x6f
b87bed00 80586128 000006e4 00000000 00000000 nt!IopXxxControlFile+0x607
b87bed34 804dfd24 000006e4 00000000 00000000 nt!NtDeviceIoControlFile+0x28
b87bed34 7ffe0304 000006e4 00000000 00000000 nt!KiSystemService+0xd0
0545ff00 00000000 00000000 00000000 00000000 SharedUserData!SystemCallStub+0x4

STACK_COMMAND: .bugcheck ; kb

FOLLOWUP_IP:
CSTDI50+10a9
f77e00a9 f3a5 rep movsd

FAULTING_SOURCE_CODE:

SYMBOL_STACK_INDEX: 2

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: CSTDI50+10a9

MODULE_NAME: CSTDI50

IMAGE_NAME: CSTDI50.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 42538bbd

FAILURE_BUCKET_ID: 0xD1_CSTDI50+10a9

BUCKET_ID: 0xD1_CSTDI50+10a9

Followup: MachineOwner
---------