Blog: Networking

While working on a task to try and synchronize thousands of a users files using Windows’ Offline Files feature, I decided to investigate this feature more closely. I haven’t used offline files much, so while reading up on this feature I discovered that there are two kinds of offline files: Regular Offline Files, and Temporary Offline Files. The regular offline files are the ones that you specify to synchronize manually by right clicking on a file/folder and choosing “Make Available Offline”. These offline files are always available offline and there isn’t a limit to the amount of data you can synchronize this way. Temporary Offline files are a different story…[more]

Temporary Offline Files:

When users access their files sitting on servers on the network, these files are cached on the local disk (if the Offline Files Feature is active). They remain available when the portable computer is disconnected from the network. 

Upon reconnection on the network, the modified files will be resynchronized with their copy on the servers (According to the Offline  files settings available thru Tools->Synchronize->Setup in any Windows explorer window). These kind of files are called temporary offline files. They are temporary in the sense that the cached copy might be erased locally after use. Usually files that have not been accessed recently will NOT be available while offline. The “Amount of disk space to use for temporary offline files” slider (seen below), applies only to these temporary offline files, NOT to the ones you manually specify. 


 

The Microsoft Exchange Server 2007 database portability feature allows a mailbox database to be mounted on any server in the same organization. In previous versions of Exchange, a database could only be mounted in the following places:

  • Recovery storage group
  • Server with the same name as the server that the database came from
  • Another server in the same administrative group

The database portability feature removes the previous limitations and handles the issues that they presented. Database portability was implemented for the following reasons: [more]

  • Reliability is improved by removing error-prone manual steps in the recovery processes.
  • For a lost clustered mailbox server scenario, the clustered mailbox server needed to be recovered before clients could access Exchange databases.
  • Exchange mailbox data is non-server specific, so accessing that data should also be non-server specific.
  • Database portability reduces the end-to-end recovery times for various disaster recovery scenarios.

At the Extensible Storage Engine (ESE) level, Exchange databases are portable. However, Exchange Server 2003 imposes certain restrictions before bringing a database online at an alternate location that do not allow databases to be portable. Database portability removes all but one such restriction, which is that the database needs to be from the same Exchange organization. A portable database is of no use, unless clients can be redirected to the mailbox data at the alternate location. With the Microsoft Office Outlook 2007 and the Exchange 2007 Autodiscover service, clients are redirected to the new server when they try to connect.

Note: Database portability is only offered for Exchange 2007 mailbox databases. Public folder databases are not portable. This is because replication between public databases is controlled by each database being linked to and accessed through a specific server. The preferred way to move public folder data between servers is to replicate it rather than copy the database files to a different server. If you copy a public folder database to a different server, it will no longer replicate with other databases.


 

During attempt to temporarily free drive space for Disk Defragmenter to run, I had stopped the IIS web service and moved the Update Services folder, which is WSUS, to another disk drive.  After running the defragmenter, I moved the folder back and started the service up again.  Later that week, I noticed that clients had not been reporting in to WSUS. 

After server reboot, the event log reported that a service failed to start.  The only automatic service that was not running was “Update Services”.   Starting the service manually allowed me to access the WSUS management console, but another event log message was written each time I restarted the service that stated: 

“Event ID: 506 - The SelfUpdate Tree is not working.  Clients may not be able to update to the latest WUA client software and communicate with the WSUS Server.” [more]

On every server, including the WSUS server, MBSA kept failing to check security updates from the WSUS server.  WSUS client check-in is served through IIS as a site called “Selfupdate”.  It is important to allow anonymous access to the directory using an IUSR account managed by IIS.  I went back to the “Update Services” folder on the disk drive and manually added the Internet Guest Account (the IUSR account that was listed as the anonymous IIS account) and gave it “Read & Execute” permissions.  Moving that folder to another drive had likely removed the IUSR permissions for the folder.

I restarted the “Update Services” service and no longer got the Event ID: 506 message.  I ran registry commands to get Windows Updates to check for updates again on one of the servers and it reported to WSUS.  A little later, other machines began to report in as well.


 

Exchange 2007 does not automatically update address lists, global address lists, or user objects subject to an email address policy. In Exchange 2003, recipient update services used to take care of this, but this services is not present in Exchange 2007. Now, you must use scheduled powershell commands to update address lists if they are build upon object attributes that can change from time to time. For example, the address lists of one of our customers are build to key on the "office location" user object attribute. However, if the attribute is changed, Exchange does not automatically recalculate the address list membership. The following scripts are a good way to keep them updated by scheduling them with the Window's scheduler: [more]

  • Get-AddressList | Update-AddressList
  • Get-EmailAddressPolicy | Update-EmailAddressPolicy

 

When trying to install updates on our Windows 2003 Server domain controllers, the install kept failing with an Insufficient Permissions error. This is strange since I am a Domain Admin on a Domain Controller. The fix from Microsoft was to go into the Default Domain Controller GPO under "Computer Configuration / Windows Settings / Security Settings / Local Policies / User Rights Assignment" and add the Domain Admin group to the following four policies: Restore files and directories, Manage auditing and security logs, Backup files and directories, and Take ownership of files and folders. This information has not been released yet from Microsoft into a public knowledge base article.


 

I needed to troubleshoot a printing problem on one of our test servers to determine if the problem was caused by software updates that I did or if it was pre-existing.  I had a snapshot of the server prior to any of my work, so I wanted to create a new snapshot so I could roll back, test, and roll forward again after the test. 

For some reason, when I rolled back the server to the earlier snapshot, I could not login with domain credentials.  The event log had recorded: “Windows cannot determine the user or computer name. (Access is denied. ). Group Policy processing aborted.”  Typically when this is seen, the computer account is messed up and you can unjoin and rejoin the computer to the domain to reestablish the account. 

After my testing was finished, I decided to go ahead jump forward to the recent backup before I rolled back.  I received the same message and could not login to the domain.  I went into the system properties and changed the PC from domain to workgroup named “workgroup”.  After this, the server asked me to reboot to finish applying the changes.  When I rebooted the server, I noticed all the software that was pushed out by group policy was now being uninstalled.  I went ahead and kept going and rejoined the server to the domain (10 – 15 minutes later to allow for AD replication).  The server asked me to reboot again after joining the domain, and it proceeded to install the group policy software that had just been removed.  Even though I could now login to the domain, there were a few things that still didn’t work quite right because of this, such as programs that GP should have been removed from a previous MW were still there. [more]

I reverted back to my snapshot again, changed the server from domain to workgroup, and let it sit for (10-15 minutes) while declining to reboot.  I joined the server back to the domain and then elected to reboot the server.  This successfully kept all of the previous software installed by GP and uninstalled the software that was specified by the previous MW GP modifications.  So to save yourself problems in the future when fixing computer account association, don’t reboot after unjoining the domain, but DO reboot after rejoining.


 

We recently ran into a problem where one of our customer's servers was randomly rebooting. It looked like the cause of this was the updates from Backup exec that were being downloaded and installed. We checked backup exec and it was not set to install updates at all. After some research we found that they updates were being installed even though it wasn't set to do so. [more]

We noticed the updates were occurring the same time as the SMSE updates. After researching with Symantec I found that by default Backup Exec is registered with LiveUpdate and is configured to receive updates ANYTIME LiveUpdate is run from ANY Symantec application configured to use LiveUpdate. Thus every time that SMSE started LiveUpdate it would install Backup Exec updates as well. I downloaded a utility (BeUpdateOps.exe) that I used to unregister Backup Exec from LiveUpdate and this stopped the random reboots.


 

When working with WSUS, I kept getting an error every time I tried to do anything with WSUS (uninstall, reinstall, start the service, start the program, etc.). The error reported that the mscoree.dll file was missing or not installed correctly and reinstalling the program may fix this error. This dll file is related with the .NET framework. Reinstalling .NET 2.0 framework fixed the problem without having to reinstall WSUS.


 

The SQL 2005 installer expects the installation media to be in a specific layout.  If the directory structure is incorrect the error message you receive during setup is: "There was an unexpected failure during the setup wizard. You may review the setup logs and/or click the help button for more information."

The behavior I saw was that the SQL server itself would install, but the Management Studio installation failed.

From http://support.microsoft.com/kb/916760:
This problem is most likely to occur if you start the SQL Server 2005 installation from a folder on a network share or on a hard disk when the folder was copied from the SQL Server 2005 installation CDs.

WORKAROUND
To work around this problem, set the folders in the correct layout for the SQL Server 2005 installation. [more]

The SQL Server 2005 installation uses the following two folders:

  • Servers
  • Tools

These two folders must be under the same level of a folder or the root folder of a drive. The names of these folders must be exactly Servers and Tools. The Servers folder contains all the files that are required to install major SQL Server 2005 components, such as database engine. The Tools folder contains tools components and Books Online for SQL Server 2005.


 

ZoomIT, is a presentation product that allows you to zoom in on a particular part of the screen during presentations… OR, to enlarge a part of the screen for readability.  This was written by the same people who wrote the sysinternals products and is available on the Microsoft download site. I saw it used extensively by many of the Microsoft presenters at TechED 2008. [more]

You can also annotate the screen during presentations by drawing graphics with the mouse or writing text to the screen.

Click here to visit the download page.