Results tagged “Software”

The swing style route to Small Business Server 2008 from Server 2000 without Exchange went pretty smooth with only a couple issues that required some minor troubleshooting. The most common swing method usually involves joining a temp server to an existing domain, running dcpromo on the temp server, disconnecting and then seizing all the active directory roles. The temp server is then used to transfer active directory to the final destination server. There's more than 1 way to migrate from Server 2000 to SBS 2008. In my case, here's an overview of what worked for me.

This migration method uses 2 virtual machines and Windows Server 2008 Standard install media. Using your virtualization software of choice, create virtual machines for a Windows 2000 server (configure same number of processors as the source 2000 server for HAL compatibility) and a Windows 2008 server. A Windows 7 loaded laptop running VMWARE Workstation is what was used for the virtual machines in this overview.

• Load the designated Server OS's (2000 and 2008) on the newly created virtual machines and configure the virtual network cards in bridge mode.
• Install, configure Windows 2000 with the same name and IP address of the source production server.
• Add static IP to the Windows 2008 virtual machine which will eventually be used as the source server for the SBS 2008 migration (I used Windows Server 2008 Standard VLM media which provides a 3 day grace activation period).

Prep the source 2000 domain controller as in Part 1

• Raise Domain Functional level of your Windows 2000 server to Native 2000
• Insert SBS 2008 setup DVD into your Windows 2000 server dvd-drive
• Run adprep /forestprep and adprep /domainprep from the Sources\Adrep directory
• Make sure the Windows 2000 domain administrator account meets the SBS 2008 password complexity requirements

Password must satisfy three of the following four categories.

• Minimum 8 characters
• Upper case lower case
• Numerals (0 through 9)
• At least 1 non-alphanumeric character

On the source Windows 2000 Server

• Run system state backup
• Restore backup to virtual Windows 2000 Server machine, reboot
• Login, review and verify restored active directory data
• Point DNS on Windows Server 2008 virtual machine to restored domain controller IP address then join domain, reboot
• Login, run dcpromo on Windows Server 2008 machine, reboot
• Login to Windows Server 2008 domain controller
• Configure DNS IP address on Windows Server 2008 to point back to it self
• Transfer all active directory FSMO roles to Windows Server 2008
• Configure Windows 2000 domain controller DNS to point to Windows 2008 domain controller
• Run dcpromo on Windows 2000 domain controller, shutdown Server 2000 virtual machine

At this point the migration to Small Business Server 2008 using your pre-filled answer file and removable device on the destination server should be straightforward. The laptop with virtual Windows 2008 server machine was assigned a static IP and designated as the default gateway in the answer file. Also make sure to raise the domain functional level on the virtual Windows 2008 domain controller to Windows Server 2003 from Windows 2000 Native.

The laptop and destination server were both connected to a separate standalone network switch (you could probably use a crossover cable as well). The migration to Small Business Server 2008 from the virtual Windows 2008 Standard domain controller ran successfully with all active directory FSMO roles automatically transferred. Active directory was uninstalled from the temp domain controller and the virtual machine shutdown.

The cutover to the new SBS 2008 server involved shutting down all the workstations, disconnecting the production server then connecting the new server to the network. It was literally a swap of the network cables from the standalone network switch to the production switch. The workstations were powered back on and the login access to the new server tested successfully. The old 2000 server was demoted while disconnected from the production network and rejoined back to the domain as a member server to preserve access to some legacy apps and to be able migrate all the current static data to the new server.

Comments or questions welcomed.

My first migration from Windows Server 2000 to Small Business Server 2008 with some setbacks and successes was an overall good learning experience. This article series will outline and discuss the steps and processes I used to successfully migrate from a Windows Server 2000 based domain without Exchange to Small Business Server 2008.

The network being migrated consisted of a single Windows 2000 domain controller and about 10 workstations. My goal was to minimize having to touch the workstations and also retain the current Windows 2000 server as a member server after the migration. Since the SBS 2008 migration process using the answer file method is not supported for migration from Windows 2000, I tried a suggested alternative referenced here.

First step was to prep the Windows 2000 active directory.

1. Raise Domain Functional level of your Windows 2000 server to Native 2000
2. Insert SBS 2008 setup DVD into your Windows 2000 server dvd-drive
3. Run adprep /forestprep and adprep /domainprep from the Sources\Adrep directory

Next, create migration answer file which will actually interrupt the SBS 2008 install

1. From the SBS 2008 DVD Tools folder, run SBSAfg.exe and fill in the required info
2. Save and copy the answer file to removable media (I used a USB floppy drive)
3. Boot new server with connected removable device and answer file

The install should halt with the dcpromo log revealing the following error:

"Failed to copy install file c:\windows\system32\sbsntds.dit to c:\windows\NTDS\ntds.dit"

From here you should have access to the SBS 2008 desktop. Configure static ip settings and server name, reboot and join domain.

As suggested from the above referenced article, the current Windows 2000 server ntds.dit file would need to be copied from the source 2000 server either through active directory restore mode boot or a redirected backup restore operation. Rename the ntds.dit file to sbsntds.dit and then copy it to the c:\windows\system32 directory on the SBS 2008 server. Run dcpromo on the SBS 2008 server and that should join it to the existing Windows 2000 domain. However, that wasn't the case for me. For whatever reason, my copied sbsntds.dit file kept logging corruption errors and the following "Active Directory is Rebuilding Indices" message during the SBS 2008 dcpromo process and ultimately failing.

This option may work for you since it looks like it has for others. After an hour or so of troubleshooting, I opted instead to do a swing style migration that I'll review soon in Part 2. Comments or questions welcomed.

For most of the SQL installs that I maintain, nightly SQL dumps to disk and then copy to tape is my preferred backup method. I use a simple maintenance plan that dumps all user databases to the local disk and then a cleanup task that purges backup files older than a set number of days. An email alert with either success or fail in the subject line is sent out after each maintenance plan task is completed. This article will review step by step how to add email notifications to your existing SQL 2008 maintenance plan.

First step is to configure Database Mail. Open Microsoft SQL Server Management Studio then right-click on Database Mail > select Configure Database Mail

Skip the welcome screen and select Next on the Select Configuration Task window.

Create new profile > fill out Profile name > Select Add under SMTP accounts:

Fill out New Database Mail Account info:

Configure Profile Security > check Public > set as Default > Next > Finish > close

Send test email. Right-click on Database Mail

Fill out test info, select Send Test Email. 

Check inbox, select OK on the confirmation screen. If you dont recieve test email then double check and verify smtp settings.

Next step is to configure Operators. Under Object Explorer right-click on Operators > New Operator

Fill out New Operator info (minimum name and email address)

Select OK.

Next, right click on designated maintenance plan (assuming one is already configured) and select Modify

This should bring up the design window with the current tasks

From the Toolbox window Drag and drop Notify Operator Task to Design window twice. One for success and the other for fail.

Connect the backup database task to each Notify Operator Task and make sure the arrows are pointing down.

Designate one of the Notify Operator Task objects connection arrows as Failure. Right click on connection and select Failure. This will turn the connection arrow red.

Double click each Notify Operator Task > check which operators to notify if there are more than one > fill out Subject and Body fields > select OK

Save Maintenance Plan and test.

One of the nice features of the Notify Operator Task in SQL 2008 that wasn't an option in SQL 2005 is the ability to add a unique subject line to the message. Its helpful to be able to see the success or fail status at a glance from just the subject line especially with the morning barrage of emails. Comments or questions welcomed. 

"Wow, that was painless" was my initial reaction after installing Sunbelt's Vipre Enterprise, configuring policies and deploying a few agents. I'm currently running Vipre and Symantec Endpoint simultaneously on the same network. It's a small Microsoft Windows based network with less than 15 users. The desktops are a mix of Vista and XP with Vipre agents running on a few of the XP machines. Before I continue with any details, here's some background leading up to this first impressions Vipre and Endpoint comparison review.

From the initial release of Symantec Endpoint till now, I've had to wade through more than a few issues. Majority of these issues are referenced in Symantec's knowledgebase or support forums. My Endpoint deployment base consists of more than a dozen customer networks ranging in size from 5 to 100 workstations. Here is a summary of some of the most common recurring issues I've experienced from late last year till now.

• Endpoint Protection Manager Console using up disk space with large temp files
• Desktop client also using up disk space with large temp files
• CPU spikes at regular and random intervals
• Outlook blocked attachment operation failed
• Random network disconnects and SMB issues with Endpoint client on Vista
• Constant high CPU utilization and usually complete lockup with Endpoint client on Windows 2000 based machines
• Windows installer rollback during Endpoint Protection Manager upgrades resulting in several complete uninstall reinstalls of Endpoint console and manual re homing of Endpoint clients

After considering the effort and time spent resolving a lot of these issues, an alternative product seemed very appealing. Back in July is when I started receiving Sunbelt's marketing emails regarding Vipre.

The Pitch

The End of Antivirus as You Know It: A First Look at VIPRE Enterprise

As part of its ongoing efforts to address the rapidly evolving malware landscape facing enterprises, Sunbelt Software introduces VIPRE Enterprise™ - a completely new solution that combines antivirus, antispyware, anti-root kit and other technologies into a seamless, tightly-integrated product...Sunbelt started with a blank slate to design a new, next-generation antivirus and antispyware technology to deal with today's malware in the most comprehensive, highly efficient manner. The result is a clean, fast, and powerful anti-malware solution developed 'by admins for admins'.

I really liked the idea of a "blank slate." Plus, who wouldn't want "...clean, fast and powerful, seamless, tightly integrated, developed by admins for admins." Almost sounds like an "all you've ever wanted, dreamed of, see it to believe it" new product sales pitch. Well after a month in use and with no major issues to report, I've been pretty happy with it. Here are some details regarding my early experience with Sunbelt's Vipre Enterprise.

First, a screenshot of the Endpoint and Vipre console and exported client install files.

Is this a case of bigger isn't always better? Or perhaps this is what Sunbelt meant by blank slate and clean.

The Vipre console install was straightforward and quick with most of the setup options already pre-checked or pre-filled. Open up the Vipre Enterprise management console and right away you'll notice an easy on the eyes, simple to navigate, common sense management interface. ( View image) I like the easy access buttons. Almost every setting is conveniently within a 1 to 3 click range. The Vipre Enterprise client also has a similar look and feel. ( View image) Sunbelt's claim "VIPRE protects without degrading performance" seems justified especially when scanning. The clients I have deployed are configured to quick scan at noon. The only noticeable indication that a scan has started is the Vipre agent systray icon color change to green. 

Endpoint with its pre-requisites (IIS, etc.), default or custom website, less than or more than 500 users database configuration and so on can take more than a few minutes to install. After years of using Symantec's classic pre Endpoint mangement app, I wasn't exactly thrilled the first time I logged into the Endpoint Management console . It took some effort to get familiar with the menu flow, tabs, tasks and all the shared non-shared policy, protection, deployment and group configuration options. In contrast, the Vipre Management console seemed effortless. On the client side, I fielded many compaints from end users regarding performance issues, cpu spikes and lockups that all appear to be attributed to Endpoint.

Alright, so the big question is, how well do the threat detection engines stack up against eachother? For this post, I ran a simple comparison test using a virtual XP machine alternating between the Vipre and Endpoint clients. Here's an overview of the test environment:

• Windows XP based laptop with VMware Workstation 6.5
• Windows XP virtual machine fresh install with no antivirus
• Pre-antivirus snapshot of XP virtual machine for instant rollback
• The malware of the day, Antivirus 2009

I chose Antivirus 2009 because within the last few months it found its way onto several Endpoint protected workstations without any action taken on it. Each test client was the most current available, had the latest definitions installed and was similarly configured. Both clients were tested several times. The virtual XP test machine was rolled back to its pre client state after each test and then the clients were reinstalled. Each client was put through the following flow of events:

• Accessed Antivirus 2009 bait laden website from virtual XP machine
• Selected OK on bait pop up screens ( View image)
• Ran through fake scan and fake results screens ( View image)
• Clicked on fake scan results to begin download of A9installer_880147.exe executable
• Selected Run at the download prompt since that's usually what the average end users do
• Clicked Continue to install, waited for the responses

• Vipre responded almost immediately. It blocked the file then deleted it. The response was identical on subsequent tests. No reboot was necessary.

• During the first test run of Symantec Endpoint, Antivirus 2009 actually completed the install. Endpoint did eventually respond and required a reboot to complete the removal action. ( View image) 
• However, Antivirus 2009 was still able to leave its mark in the form of an Internet Explorer hijack of some sort. ( View image)
• The Antivirus 2009 install never completed on the next 2 Endpoint tests but was still able to drop a few files on the system which Endpoint succesfully quarantined. A reboot was still required to complete the removal on each of the subsequent tests.

Conclusion

Obviously, my simple test and brief comparison review is neither extensive nor thorough enough to be conclusive in any way regarding Sunbelt Vipre's overall performance ability and standing among its competitors. Although my initial review of Vipre is but a mere peek under the hood, I do like what I've seen so far. I think the greatest test will be how well Sunbelt Vipre Enterprise performs in the wild over time and how well it lives up to its claims. For more info on Vipre and links to more extensive reviews of the product visit their website. 

http://www.sunbeltsoftware.com

Comments welcomed.

Although there are already a handful of existing internet forums and knowledge base references to this topic, this post is my contribution regarding what has worked well for me. My main source on how to configure Backup Exec to work with firewalls can be found here: http://seer.entsupport.symantec.com/docs/299245.htm

The configuration and settings below are from an actual production environment. The network utilizing this configuration has Backup Exec 12.5 installed on a dedicated backup server on the LAN at 192.168.1.x with an external scsi connected LTO tape drive. The DMZ network 172.16.10.x contains several Windows based web servers. On the backup server, Backup Exec remote agent TCP dynamic port range was configured per Symantec's recommendation.

In Backup Exec select Tools > Options > Network and Security

The relevant PIX code:

ip address dmz 172.16.10.1 255.255.0.0
nat (dmz) 1 0.0.0.0 0.0.0.0 0 0

<- LAN based backup server static mapping ->
static (inside,dmz) 192.168.1.x 192.168.1.x netmask 255.255.255.255 0 0

<- Backup Exec server and remote agent port ranges ACL ->
access-list 102 permit tcp host 172.16.10.11 host 192.168.1.x range 6101 6106 
access-list 102 permit tcp host 172.16.10.12 host 192.168.1.x range 6101 6106
access-list 102 permit tcp host 172.16.10.13 host 192.168.1.x range 6101 6106
access-list 102 permit tcp host 172.16.10.11 host 192.168.1.x range 10000 10500
access-list 102 permit tcp host 172.16.10.12 host 192.168.1.x range 10000 10500
access-list 102 permit tcp host 172.16.10.13 host 192.168.1.x range 10000 10500

<- Enable ACL ->
access-group 102 in interface dmz

Backup Exec remote agents installed successfully on the web servers via push. A DMZ backup job was then configured and scheduled. 

Here's a screenshot of the DMZ backup job throughput:

Comments or questions welcomed.

Earlier this year I had an opportunity to try out Jeff Middleton's SBS 2003 migration kit with a small 15 user network. An HP ML370 G4 server running SBS 2003 was being replaced with an HP ML370 G5 server. The new server was prepped and configured with identical name, disk partition layout and network settings in workgroup mode. I loaded up a laptop with Windows 2003 server, called it TempDC, joined it to the customers existing domain, ran DCpromo, enabled Global Catalog role then replicated DNS and Active Directory. The next step was to remove the laptop from the customer network, seize the FSMO roles and clean up Active Directory.

The same scenario was then performed with the new server pulling Active Directory from the laptop. The rest of the SBS 2003 setup on the new server continued after migrating Active Directory and completed without any issues.

The cutover was done on a Saturday. The customer's production data was backed up to an external hard drive Friday evening using Symantec Backup Exec. The Exchange Store database files were also copied over to the same drive. On Saturday, the external hard drive was connected to the new server, inventoried and cataloged. The Exchange Store database files were copied over first to the same path on the new server and successfully mounted. The data was then restored. The remainder of the day was spent making sure all the typical functions of the server were in order and accessible. Shares, security, printing, login scripts, etc.

On Monday morning the users logged in as usual with only a few minor issues. Jeff's swing kit was easy to follow, provided good detail and offered solutions to common issues that may arise during the various steps of the swing migration process.

More info:  http://www.sbsmigration.com/

Last week I had a client call in with an Antivirus XP 2008 infection. I connected remotely to the client's computer using Crossloop and began the removal process. Deleting related dll's, executables, registry entries, etc. After rebooting to complete the removal process and logging in, the user reported that there were no icons and the entire desktop was blank. Same thing after a second reboot. At this point I'm having remote session withdrawals and thinking I'll have to drop by for an onsite visit. As a last resort, I had the client reboot a 3rd time into safe mode with networking and to my surprise CrossLoop came right up and I was able to re-establish a remote session. I found and deleted some additional registry entries where Antivirus XP 2008 had modified theme, screensaver and wallpaper info. Rebooted and the computer appeared to be back to normal.