Tuesday, September 29, 2009

Managed vs. Unmanaged Code

While reading through the Internet Information Services 7.0 Resource Kit, I repeatedly came across the concept of unmanaged and managed code. A quick Google search later and it all makes sense (almost)! Thanks Kate Gregory!!

Monday, September 28, 2009

Installing a SSL Certificate on SBS 2008

The Short Story:
Want a cheap but trusted SSL certificate for SBS 2008? GeoTrust's RapidSSL certs are $19.95 per year through eNomCentral and seem to be trusted by enough devices to make me a happy camper. eNomCentral has a few minor downsides (see below for the whole story), but all in all it was a fine experience. The remote site works, Connect to a Computer works, the only thing left to test is Outlook Anywhere, but that is for another day (EDIT: Outlook Anywhere works flawless!). You can test out the RapidSSL cert for free for 30 days using the FreeSSL option just to make sure it fits your needs.

The Long Story:
The time has come to install a SSL certificate on my SBS 2008 server. I recommend reading this amazing post by Sean Daniel which held my hand through most of my ordeal. I decided to go to enomcentral.com to get my cert since it's one of the three major registrars that SBS 2008 supports for automatically handling your public DNS settings. While I don't plan on using that service, at least I know there's a relationship between SBS 2008 and enomcentral.com. I hoped that that would bode well for me.

On enomcentral's site, I perused through the available SSL certificates and honed in on GeoTrust's RapidSSL certificate. Verisign certs were absurdly expensive and SBS Certificates (The SBS stands for Secure Business Services and not Small Business Server -- that was a bit confusing at first) seemed just a tiny but seedy based on my limited research. I know the name GeoTrust and figured that there was no doubt it would be trusted by most devices. Also, GeoTrust RapidSSL certs were $19.99 as opposed to SBS Instant certs being $29.95. I picked a 5 year certificate.

Saturday, September 26, 2009

"Connect to a Computer" link not visible across the WAN, but can see it on the LAN

My Problem
When a user connects to the "remote.companydomain.com" site remotely, they can see the "Check Email" and "Internal Web Site" links, but not the "Connect to a Computer" link. When connecting to the site from within the company's LAN the link appears.

My Solution
Use Internet Explorer as your web browser. My problem was that I was using every browser under the sun except IE. How do I loathe IE? let me count the ways.

Thursday, September 24, 2009

Dear receptionist Ashley at Bethesda Medical Center at Arrow Springs

Dear receptionist Ashley at Bethesda Medical Center at Arrow Springs,

I spoke to you over the phone today to make an appointment. You are the most pleasant doctor's receptionist I have ever spoken to. This is either due to you being fresh out of school and not being dragged down by the dragons that double as receptionists or you found where the doctor keeps the Vicodin samples. Or maybe your parents were Care Bears. Speaking to you was like running through the end of the rainbow with a bubble machine.

Thank you Ashley. It's two hours after we spoke and I still feel all warm and fuzzy.

Solving local users not appearing in the Connect Computer application when adding a computer to the SBS 2008 domain; Part 2

My Problem
(In reference to this issue I had) A user will not show up in the Connect Computer application. After creating a brand new user and ensuring that the new local user can be seen by the Connect Computer application I then moved the old user profile data to the new user profile folder. However, the formerly visible new user profile then becomes invisible to the connect computer app. Removing those files causes the profile to reappear in the Connect Computer app.

In other words, the solution that I used for a previous user account on another computer (documented in the link above) did not work on this machine.

My Solution
This was a bit sneaky and probably not the best way to do it, but I was desperate and so far it seems to work. Created a new local user account and then run the Connect Computer application. The new account should be visible to map a domain account to. Then, without exiting the app, delete all files in the new user profile folder, move all files over from the old user profile folder, switch back to the still running Connect Computer application and clicked "next" without rescanning the profile folders.

This may have some undesirable effects. For instance, The Outlook 2002 preferences of the user were reset, but the pst file was fine. I had to re-create the POP3 mail accounts and reset some of the visual preferences.

The Long Story

When I noticed that the existing user account was not visible in Connect Computer, I created a new local user account (after banging my head on the keyboard) and then checked to make sure the new account was visible in the Connect Computer application. I then deleted all files in the new user profile folder, moved all files over from the old user profile folder, switched back to the still running Connect Computer application and clicked "next" without rescanning the profile folders.

It hung for a while at the "assigning users" step which worried me. I did a ctrl-alt-del from the minimal user interface that the SBS application presents and noticed that it said a user nameed __sbs_netsetup__ was logged on. I launched Task Manager and noticed that MoveUser.exe was indeed taking up CPU cycles. Hmmm... maybe it was just taking a little while because the user's profile was over 60GB. After almost 10 minutes it finished and automatically rebooted.

After rebooting it was logged in automatically as the domain administrator and not the user account that I had ported over. That worried me since all my previous experience had involved the user account that was ported over being logged in after the first reboot.

I logged off and tried to log on as the user and was mercifully greeted with their desktop icons. All looked well, except Outlook (version 2002!) behaved strangely. The POP3 accounts were gone and I had to recreate them. The visual elements like which folder Outlook went to on startup was changed back to default. All in all I accepted it as a success. It's certainly not the most elegant solution and I hope to get to the bottom of things, but it could have been worse...

Tuesday, September 22, 2009

Monday, September 21, 2009

Security logs on client PCs fill up after joining a SBS 2008 domain

The Problem:
After joining a PC to a SBS 2008 domain, you may soon notice that users cannot log into the machine and the following error is displayed on the logon box: "The security log on this system is full. Only administrators can log on to fix the problem." Or if you log in via RDP you will see the logon message "The security log on this system is full."

The Solution:
Change the log size and/or retention settings for the security log. You can either do this locally or via a GPO.

Locally: Open event viewer (run >> eventvwr), right click the security log, select properties and edit the appropriate settings under the "Log Size" section. Increase the log size for a temporary fix or select "Overwrite events as needed" or "Overwrite events older than" and select a value in days that you're sure won't cause the log to fill up before that number of days has passed.

From a GPO: Look at the options for Security Logs in the following GPO node: Computer Configuration >> Policies >> Windows Settings >> Security Settings >> Event Log. Specifically, I chose to edit the "Maximum Security Log Size" and "Retention Method for Security Log" options.

The Long Story:
After I joined the very first client to my new SBS 2008 domain, I noticed an error upon logging in via RDP: "The security log on this system is full." It was an XP SP2 machine and when I checked the security log I noticed a ton of event numbers 538, 540 and 576 (Logon/Logoff and Privilege Use events). They were logged for users MyServerName$ and SBSMonAcct.

A quick search of the SBSMonAcct user reveals that it is a special account that is created, used and deleted on the fly by SBS 2008. So apparently there's a lot more interaction on the SBS machine's behalf with the client PCs than I first knew about. The security log settings on the XP client were set to cap the security log at an underwhelming 64K and to retain the log for 7 days. With all of those logon/logoff events the log was filling up well before the 7 day limit. I wanted to make sure this didn't happen on any other machines on the domain.

On the SBS box, I edited the "Windows SBS Client Policy" GPO that is created by default and linked to the default SBSComputers OU. I moved to the following GPO node: Computer Configuration >> Policies >> Windows Settings >> Security Settings >> Event Log. I edited the following options:

  • Maximum Security Log Size: 16,384 kilobytes (the default when you enable this policy)
  •  Retention Method for Security Log: Overwrite events as needed (This place isn't a high security environment and I think 16 megs of security events should be enough. If I need to retain more than that I can change the settings as needed.)
And all was well in the land.

Saturday, September 19, 2009

Joing a Server 2003 computer to a SBS 2008 domain

My Problem:
Trying to join a Server 2003 machine to the domain via the SBS Connect Computer application resulted in the following error:

This computer does not meet the requirements necessary to connect to the network. Supported Operating System Not Found. To joing your computer to the Windows SBS network using the Connect Computer program, you must be running...

My Solution:
Simply add the Server 2003 computer to the domain manually using the "Computer Name" tab in "System Properties". Once the member server has been added, go into Active Directory Users and Computers and move the server from the SBSClient OU to the SBSServers OU. This TechNet document is my source: http://technet.microsoft.com/en-us/library/dd469602%28WS.10%29.aspx

The Long Story:
While attempting to join a Server 2003 machine to my new SBS 2008 domain, I received the above error. For a split second I panicked thinking that for some strange reason Server 2003 could not be joined to the domain. I knew this to be absurd... and yet I didn't want to assume that Microsoft was more sane in some of its practices than what prior experience had proven. Some quick Googling proved that indeed Server 2003 can be a member server. However, the only trick to the process is to make sure you move the newly joined server to the SBSServer OU to keep the client PC GPOs from applying to the Server.

Thursday, September 17, 2009

Solving local users not appearing in the Connect Computer application when adding a computer to the SBS 2008 domain

The Problem:
When joining a computer to a SBS 2008 domain using the Connect Computer application, you may not see some or any local user profiles in the "Move existing user data and settings" dialog box. This can happen even if the "Make this folder private" option is deselected for the user's profile folder within Documents and Settings.

The Solution:
Copy the user profile folder to a new place (I used System Properties >> Advanced Tab >> User Profiles >> Settings >> Copy To) and then delete the original user profile folder. Log in with the user account so that a new profile folder is created. Delete all contents of the new user profile and copy over all contents of the old user profile. You will now be able to see the profile in the SBS Connect Computer application.

NOTE: You may want to first try renaming the NTUSER.DAT file as well as the NTUSER.DAT.LOG and NTUSER.INI files. However, that did not work in my situation and I had to completely recreate the user profile folder.

The Long Story:
I was attempting to join a user's computer to my SBS 2008 domain with the Connect Computer program. On the "Move existing user data and settings" dialog box I was dismayed to find that the drop down lists underneath the "Old logon name" heading were not populated with any user accounts. It was as if it didn't see any local user profiles.

The standard thing to check at this point is if the user profile folders that you are interested in have the "Make this folder private" option enabled which enacts "Level 1 Security" on the folder. Simple file sharing needs to be turned on to see that exact option. In my case, that option was deselected like it should have been.

I went to a different computer and ran the Connect Computer app and on the "Move existing user data and settings" dialog box I was able to see two of the eight profiles! I tried to figure out why those 6 profiles were not visible to the SBS app. Of the 8 total profile folders, only three of the corresponding accounts still existed on the local computer. Of those three accounts on the computer, only two were shown in the Connect Computer app. At this point I suspected that for the profile to be seen, the corresponding user account had to exist on the local computer. This might seem obvious at first, but initially I thought it would search for profile folders regardless of the user account existence.

First in my troubleshooting efforts was to create a brand new local user. After I logged in as that user to create the profile folder, I was able to then choose that profile in the Connect Computer app. I then deleted the newly created user and could not see that profile as an option in the Connect Computer app. That proved that in order for the profile to show up in Connect Computer, there had to be a corresponding user in the local SAM. However, this concept seemed to be thwarted by the fact that there was one profile that was not displayed in Connect Computer even though the user account still existed on the machine.

I decided to investigate that one user account that still existed on the machine but wasn't showing up in Connect Computer. When I logged in I saw the "Personalized settings... setting up personalized settings for Themes Setup" dialog box as if I was logging into a profile for the first time. Hmmm... maybe somehow the connection between the user account and the profile had been broken? But just what is that connection between the account and the profile folder? I didn't know enough about Windows accounts to know. I had a vague idea that it might have something to do with the NTUSER.DAT file.

After that user had logged in, I checked the Docs and Settings folder and noticed a new user profile folder in the format of [username].[computername]. Ouch. It had indeed created a new user profile. Somehow the connection between the original profile folder and the user account had been broken. I deleted the entire [username].[computername] folder and then went into the original [username] folder and deleted the NTUSER.DAT and NTUSER.DAT.LOG files hoping that it would create a new set of files. It didn't work. Logging in caused the creation of a new profile folder.

After much frustration and hacking, it seems that the only way to get an existing user account to use the information in an older profile is to move the profile folder to a different place, log in with the user to have a brand new profile folder created, delete all of the newly created files and folders in the profile and move over all of the old files from the old profile folder. You should now be able to see the user account in the Connect Computer app.

For more information about moving profile information, read MS KB 811151.

Sunday, September 13, 2009

Solution to error 0xc0000135 with SBS 2008 Connect Computer application

The Short Story:
At least version 2.0 of the .NET Framework is required to run the Connect Computer application. Install the latest .NET framework (Microsoft .NET Framework 3.5 Service Pack 1 in my case).

The Long Story:
I have a Windows XP SP2 machine that I browsed to the SBS 2008 connect computer web site with. I downloaded launcher.exe and opened it. After a few brief moments I was met with the error "The Application failed to initialize properly (0xc0000135). Click on OK to terminate the application." Super!

A quick Google search of that error number revealed a simple solution. It appears that that error message is indicative of the .NET framework not being installed. $60 billlion in yearly revenue and Microsoft can't at least mention ".NET Framework" somewhere in that error message?

I went to the Windows Update site and installed the Microsoft .NET Framework 3.5 Service Pack 1 and all was well. Huzzah!

Friday, September 11, 2009

Antivirus exceptions after moving Exchange 2007 files on SBS 2008

When using the SBS Management Console to move Exchange files, it moves the mailbox and public folders stores. Much of the files, folders and file types that need to be excluded remain on the original drive (the system drive by default) so many of the exceptions shouldn't change. However, to make it easier after moving the Exchange files, I simply masked out the entire "Exchange Server" on the drive that I moved the Exchange data to. E.g.: "E:\Program Files\Microsoft\Exchange Server\"

Not that I'm suggesting that this is the best way to handle things, but it seems to simplify the exclusion process without any unwanted side effects.

Wednesday, September 9, 2009

Antivirus Process Exclusions for Exchange 2007 on SBS 2008 Standard Edition

I blogged about a mammoth list of file, folder, process and extension exceptions that are needful for Microsoft's Small Business Server 2008 Standard Edition over here. However, the process exclusions list for Exchange 2007 requires a more thorough treatment.

I use Kaspersky Antivirus for Windows Servers Enterprise Edition on the SBS 2008 machine and it requires me to feed it the actual executable file in order to exempt it from the real-time scanner. This posed something of a problem as I was then required to track down the path to each individual executable file. Here's the list of executables the need to be exempted and where you can find them. The list is broken into two categories: Those that I could find and those that I could not.

Executables that I could find:
•    edgetransport.exe  ( C:\Program Files\Microsoft\Exchange Server\Bin\ )
•    mad.exe ( C:\Program Files\Microsoft\Exchange Server\Bin\ )
•    Microsoft.Exchange.Antispamupdatesvc.exe ( C:\Program Files\Microsoft\Exchange Server\Bin\ )
•    Microsoft.Exchange.Cluster.Replayservice.exe ( C:\Program Files\Microsoft\Exchange Server\Bin\ )
•    Microsoft.Exchange.Edgesyncsvc.exe ( C:\Program Files\Microsoft\Exchange Server\Bin\ )
•    Microsoft.Exchange.imap4.exe (as per this article it can be found in C:\Program files\Microsoft\exchange server\clientaccess\popimap\ )
•    Microsoft.Exchange.imap4service.exe (see above)
•    Microsoft.exchange.pop3.exe ( C:\Program Files\Microsoft\Exchange Server\ClientAccess\PopImap\ )
•    Microsoft.exchange.pop3service.exe  (see above)
•    Microsoft.Exchange.Search.Exsearch.exe ( C:\Program Files\Microsoft\Exchange Server\Bin\ )
•    Microsoft.Exchange.Servicehost.exe ( C:\Program Files\Microsoft\Exchange Server\Bin\ )
•    Msexchangeadtopologyservice.exe ( C:\Program Files\Microsoft\Exchange Server\Bin\ )
•    Msexchangefds.exe ( C:\Program Files\Microsoft\Exchange Server\Bin\ )
•    Msexchangemailboxassistants.exe ( C:\Program Files\Microsoft\Exchange Server\Bin\ )
•    Msexchangemailsubmission.exe ( C:\Program Files\Microsoft\Exchange Server\Bin\ )
•    Msexchangetransport.exe ( C:\Program Files\Microsoft\Exchange Server\Bin\ )   
•    Msexchangetransportlogsearch.exe ( C:\Program Files\Microsoft\Exchange Server\Bin\ )
•    Msftefd.exe ( C:\Program Files\Microsoft\Exchange Server\Bin\ )
•    msftesql.exe ( C:\Program Files\Microsoft\Exchange Server\Bin\ )
•    oleconverter.exe ( C:\Program Files\Microsoft\Exchange Server\Bin\ )
•    PowerShell.exe ( C:\WINDOWS\System32\WindowsPowerShell\v1.0 )
•    transcodingservice.exe ( C:\Program Files\Microsoft\Exchange Server\ClientAccess\owa\bin\DocumentViewing\TranscodingService.exe )
•    store.exe ( C:\Program Files\Microsoft\Exchange Server\Bin\ )
•    w3wp.exe ( C:\Windows\System32\inetsrv\ )

Executables that I could not find:
•    cdb.exe (Symbolic debugger for Windows. This doesn't seem to be a big deal that I couldn't find it. In fact, it might be something that's not included with Windows but something that you have to download and add on.)
•    cidaemon.exe (cidaemon.exe is an indexing service which catalogues files on your computer to enable for faster file searches. According to what-is-exe.com it should be at c:\windows\system32\cidaemon.exe but it is not there on my installation of SBS)
•    cluster.exe (Seems to be only applicable if Exchange is in a cluster which, in my case, it is not so I didn't worry about it)
•     dsamain.exe (dsamain.exe is a AD/AM Active Directory Application Mode from Microsoft Corporation belonging to ADAM Active Directory Application Mode. This worries me a little bit that I can't it.)
•     edgecredentialsvc.exe (It keeps the track of any credential changes on ADAM. It will update the credential changes on Edge Transport. It's supposedly in C:\Program Files\Microsoft\Exchange Server\Bin\EdgeCredentialSvc.exe but it's not in my installation of SBS 2008 for some reason )
•    galgrammargenerator.exe (As per this KB article, it appears that it should be in the :\Program Files\Microsoft\Exchange Server\Bin folder but it's not for my installation)
•    microsoft.exchange.contentfilter.wrapper.exe (I have no idea what this is or where this is supposed to be)
•    microsoft.exchange.infoworker.assistants.exe (as per this thread it should be found at C:\Program Files\Microsoft\Exchange Server\Bin\ but I didn't see it on my installation. Closest thing I have is Microsoft.Exchange.InfoWorker.AssistantsClientResources.dll )
•    Microsoft.Exchange.Monitoring.Exe (C:\Program Files\Microsoft\Exchange Server\Bin)
•    sesworker.exe (As per this article it is involved in the speech server portion of exchange. I'm not sure if SBS can do that or not so I'm not sure if it would even exist on my installatoin. sesworker.exe.config files are in C:\Program Files\Microsoft\Exchange Server\UnifiedMessaging but no sign of the executable )
•    speechservice.exe (According to this KB article the speechservice.exe file is located in %Programfiles%\Microsoft\Exchange Server\UnifiedMessaging . It's not in that folder on my installation. )
•    umservice.exe (According to this thread it should be located at E:\Program Files\Exchange server\bin\umservice.exe but I couldn't find it there even though the UMService.exe.config was there. )
•    umworkerprocess.exe (According to this page The default location is at C:\Program Files\Microsoft\Exchange Server\bin but I can only find the UMWorkerProcess.exe.config file and not the actual exe )

Executables that are really, really weird: (Okay, I lied. There are three categories)
•    inetinfo.exe (inetinfo.exe is used primarily for debugging Microsoft Windows Server Internet Information Services is the IIS web server service. I was confused as to it's debugging properties as a result of some threads on the web. Thanks to commenter "Joe Webster" for pointing that out. As per this thread it appears that it should be in the following location: C:\WINDOWS\system32\inetsrv\inetinfo.exe In fact I did find the executable there [as per this page, it could also be in the following locations: C:\Windows\inetinfo.exe, C:\Windows\system32\inetinfo.exe, C:\Program files\%subfolder%\inetinfo.exe, C:\inetinfo.exe]. However, for some strange reason I cannot see the .exe file when I browse to it in the kaspersky MMC console's dialog box to add it to the process exclusion list. It can be seen in Windows Explorer, but not from within Kaspersky's application to browse to the file. It does not help to run the Kaspersky MMC snap-in as an administrator. )

Tuesday, September 1, 2009

Default gateway disappears on Broadcom NC Series 1Gb integrated NIC in HP ML115 G5 Server

I have an HP ML 115 G5 server using the integrated Broadcom NC Series NIC. The operating system is Windows Small Business Server 2008 Standard Edition. I noticed that the static default gateway set in the TCP/IPv4 settings would disappear after a reboot. All other statically assigned TCP/IP information remained such as the IP, subnet mask and DNS servers. I was using the 12.0.0.x Broadcom drivers supplied by HP and also tried the 11.7.0.x version drivers. I then used the Windows built-in Microsoft Broadcom NetXtreme Gigabit Ethernet driver (date 8/1/2006) version and the symptom did not exist.

The solution for me was to use the HPSUM utility to check for drivers and install version of the HP Broadcom driver. The server now retains the static default gateway information after a reboot.