A nice feature of Symantec Backup Exec is it’s ability to backup directly to removable media, such as USB hard disk drives. This can be extremely handy if your primary backup device, such as as tape unit, develops a fault. To create a removable backup to disk folder and re-target your current backup job(s) perform the following:
1. Ensure you have connected your removable media and that it has been formatted and assigned an appropriate drive letter in your Windows operating system.
2. Open Backup Exec 2010 and click the “Devices” tab. In the devices sub window, right click your server name and then select “New Removable Backup-to-Disk Folder” from the available context menu.
3. Follow the Backup to Disk Wizard, and when prompted for a path to your backup to disk folder click “…” to browse and select your removable media drive from the resources window.
4. Complete the rest of the wizard, filling the the values as required. The maximum file size is generally set the size of the removable storage device, the maximum backup sets per file can be left at the default of 100, and the low disk space threshold can be left at it’s default also.
5. Once the creation of the backup to disk folder is completed, you will now notice a new device listed under the “Devices” tab in Backup Exec. If you did not name your device during the creation wizard you will see it listed as “Removable Backup-to-Disk Folder 1”. If you expand the device you will notice a folder will be visible (FLDR000001) denoted by the USB symbol. “Right click this folder and select associate with media set”. From here you can place the folder in the media set that your backup job is targeted at.
6. Now you have associated the removable backup to disk folder with your media set, it is recommended you re-target you backup job to point to the removable media device we have created. To do so click the “Monitor” tab in Backup Exec and double click your required backup job. When the backup job properties window opens, select “Device and Media” from the sub menu’s located on the left. Using the drop down menu available under the device section, select your removable media drive and click “Submit” to save your changes. This will now re-target your backup job to your removable media.
As a side note, if you are backing up a large volume of data expect your job completion time to exceed 12 hours. Typically you won’t receive a data rate higher than 300 megabytes a minute using a removable media device. More information on this process can be found at the following Symantec knowledge base article: http://seer.support.veritas.com/docs/253764.htm
From time to time, across several infrastructures, I often get people report they cannot push anti-virus agents to workstations from McAfee’s ePolicy Orchestrator. This can be time consuming and frustrating, and as you’ll know ePO isn’t the most user friendly or affective application. You can however manually install the McAfee Agent and then force it to comply with your anti-virus policies or client tasks. To do this, perform the following actions:
1. On the affected machine browse to the following location: \\EPOSERVERNAME\C$\Program Files\McAfee\ePolicy Orchestrator\DB\Software\Current\EPOAGENT3000\Install\0409\
2. Double click the FramePkg.exe file and let the agent install. Please note, you will need administrative rights over the workstation to perform this.
3. Open a command prompt window and type the following: cd “C:\Program Files\McAfee\Common Framework”
4. Once in the aforementioned directory, type the following at the command prompt and press return: CmdAgent.exe /s
5. You will now be presented with the McAfee Agent console, click “Collect and Send Props”. This prompts the agent to advertise itself to the ePO server and enforce any policies or client tasks that maybe set, which in my case is usually the installation of the ant-virus product itself.
I hope this eases your ePO frustrations, it certainly did mine.
I was presented with an issue around one month ago that was very interesting. An Exchange 2007 environment where public folders could be seen and used by Outlook clients but could not be viewed in the Public Folder Management Console or be queried through Windows Powershell. This is an extremely poorly documented issue on the internet, and there are many posts on several forums and blogs asking the same question but unfortunately with no resolution. I have found that public folders cannot be viewed in the Public Folder Management Console if one of the following conditions is true.
1. An Exchange 2003 to Exchange 2007 migration has been performed and the public folder hierarchy structure was not moved to the new Exchange organisation.
2. Public folder database corruption has occured and the database has been repaired using ESEUTIL.
If either of these conditions are true, and you cannot view system of default public folders in the Exchange Public Folder Management console you will need to recreate your storage group and public folder database. If you have tried to remove your public folder database following Microsoft TechNet guidelines you will be aware that attempting to remove it’s replica’s using Powershell will not work. To remove the database, perform the following actions:
1. Backup all of your public folders manually. This can be performed by creating a new archive PST on an Outlook client and then copying each public folder to the archive location. In addition, make a note of all e-mail addresses that are associated with mail enabled public folders. This PST will come in handy later if your database has suffered corruption.
2. Open the Exchange Management Console, expand the Organization container and click Mailbox. From the mailbox options, select the Offline Address Book tab, right click the offline address book and select properties. Select the distribution tab and then uncheck “Enable public folder distribution” as shown in the screenshot below. This removes the OAB association with the public folder database we want to delete.
3. In the Exchange Management Console, dismount the public folder database. Navigate to the folder where your database is contained, right click the EDB database file and make a copy of this to an alternate location. If your database is not corrupt, this will come in handy later.
4. Open ADSI Edit, if you are running Windows 2008 this will be pre-installed and can located under the servers Administrative Tools. If you are running Windows 2003 however you will need to download and install the Windows Server 2003 Support Tools from here.
5. In ADSI Edit connect to the configuration Naming Context. When this is displayed expand configuration and navigate to CN=Services -> CN=Microsoft Exchange -> CN=Your Organisation Name -> CN=Administrative Groups -> CN=Exchange Administrative Group (FYDIBOHF23SPDLT) -> CN=Folder Hierarchies. Right click the Folder Hierarchies container and select delete. Click OK to delete all sub objects of this container also. This action removes the heirarchy attribute for the public folder database we want to delete, this attribute will be automatically recreated at later stage.
6. In the same ADSI window, expand CN=Servers -> CN=Your Server Name -> CN=InformationStore. Highlight container CN=Second Storage Group, right click this container and select delete. Click OK to delete all sub objects of this container also.
7. Open the Exchange Management Console and expand the Server container and click Mailbox. You will now notice that your Second Storage Group and Public Folder Database are no longer listed. In the actions pane of the Mailbox window click “New Storage Group” and follow the creation wizard. Once the storage group has been created click “New Public Folder Database” and follow the creation wizard. Please note, if an error occurs during the last step of the wizard relating to mounting the new database, click finish and then manually mount the new database yourself. If your interested you will now see through ADSI Edit that the two containers we deleted earlier have now been recreated.
8. Expand the Organization container and click Mailbox. From the mailbox options, select the Offline Address Book tab, right click the offline address book and select properties. Select the distribution tab and then check “Enable public folder distribution”, in effect the reverse action of step two. If this is not performed any down level Outlook clients, such as 2003, will not be able to utilise the OAB.
9. Now the new database has been created you can attempt to either restore the database you backed up in step 3 or restore the public folders individually from an Outlook client using the PST created in step one. To decide which method you need to use, open the Exchange Management Console, select the Server container and then click Mailbox. Dismount the public folder database, then right click the database and select properties. Place a check next to the ” This database can be overwritten by a restore” option as shown in the screenshot below.
10. Browse to the file location of the new public folder database and then copy the backed up database from step 3 so that the existing database is overwritten. Return to the Exchange Management console and mount the database. If you cannot see public folders in the Public Folder Management Console, your database has suffered corruption. Unfortunately performing integrity, repair and defragment operations through ESEUTIL do not resolve this problem. If the database is corrupt you will need to perform steps 1-9 of this guide again, and then use your PST file to restore the public folders. Please note, if the PST method is used you will need to mail enable any public folders that previously had this functionality again. Public folder permissions however, are kept intact when restoring via PST.
While this is a slightly lengthy process, removing the storage group, database and it’s related Active Directory attributes will resolve this issue.
Recently I found myself in a situation where someone had deleted the contents of a SAN LUN that was used to host a proportion of virtual machines for a VMware vSphere infrastructure. Thankfully, there was a full backup of all virtual machines at my disposal. After restoring a virtual machine to an alternate location and then uploading it to the datastore, I experienced the following error when attempting to start the VM:
“Failed to open disk scsi0:0: Unsupported and/or invalid disk type 7. Did you forget to import the disk first?Unable to create virtual SCSI device for scsi0:0, ‘/vmfs/volumes/4a8075b3-4e4bf1b8-28e40017a48d6112/VMFolder/VirtualMachine.vmdk’ Module DevicePowerOn power on failed.”
After some research, it emerged that this issue was due to the fact all of the virtual machines were thin provisioned when created. When restoring a backed up virtual machine that has been created using a product such as Symantec Backup Exec 2010, a 2gbsparse disk is created that cannot be used with virtual machines hosted in ESX, which causes the error listed above. To resolve this issue we need to essentially convert the thin provisioned disk to a thick provisioned disk. This can be achieved by performing the following:
1. Log into the root of an ESX host using an SSH client
2. Change directory to the location of the restored virtual machine
3. Run the following command: vmkfstools –i “Thindisk.vmdk” -d zeroedthick “Thickdisk.vmdk”. Please note, replace thindisk with your restored vmdk file name, and replace thickdisk with the new name for the vmdk file.
4. The clone operation will now start and a percentage complete indicator will be displayed. Once this is finished the thick provisioning of the vmdk will be complete and you will now be able to start your virtual machine. Please note that you will need sufficient space on your LUN to allow for the thick provisioning.
After recently rebooting a Microsoft ISA 2006 server, I found myself in the situation of being unable to establish VPN connectivity to it from a remote location. After performing several troubleshooting methods, I identified that there were no available PPTP RAS ports listed in the Routing and Remote Access (RRAS) console.
This explained why VPN connections could not be established, however I could see that a pool of ten ports had been configured but for some reason were not available. Some research on this issue led me to identify this was the result of a recent Windows Update. If you have applied KB 956570 to your ISA Server and then rebooted it, you may find yourself in the same situation. To resolve this issue, perform the following actions on the affected server:
1. Click Start and select Run
2. In the Run dialog box enter the following registry command to reset the servers reserved port threshold. Please note, enter this command without the quotation marks:
3. To uninstall the update, please run the following script which has been provided by Microsoft for this purpose. I have collated this script, which can be downloaded here for your convenience.
4. Create a new folder on the C: drive of your ISA Server named KBFix and copy the downloaded script (KB956570.vbs) to this folder location.
5. Open the command prompt and browse to the new folder you have just created. This can be achieved by typing cd c:\kbfix and then pressing return on your keyboard.
6. Once in the correct directory type cscript KB956570.vbs and then press return on your keyboard. This will now start the process of removing the update.
7. Once the removal process is complete, reboot your ISA Server and VPN connectivity will be restored.
I’m sure we can all agree that setting global client side mailbox limit’s in Exchange 2007 is a straight forward task to perform. However, I have recently identified on several deployments still running Service Pack 1 that when setting client side limits on a mailbox database, they fail to apply correctly. While this should be a instant change, in some cases the change does not apply at all. To save hours of searching around for a limit you think you might have missed, performing the following will temporarily resolve the issue:
1. Click Start and select Run
2. In the Run dialog box type services.msc
3. In the Services console locate the Microsoft Exchange Information Store service, right click it and select restart. Please note that restarting this service will temporarily dismount your mailbox and public folder databases.
4. Close and reopen Outlook / OWA and the limit warning will no longer be visible.
To completely resolve this issue it is recommended that Exchange Service Pack 2 is applied. I would also recommend applying any outstanding rollup updates, at the time of this entry Rollup Update 4 is the latest release. See below for direct links to these updates.
Since upgrading from version 12.5 of Symantec Backup Exec, my virtual machine backup job had consistently failed. As highlighted by a colleague of mine, Backup Exec 2010 no longer utilises VMware Consolidated Backup (VCB) as it’s method of VM backup, but a new API called vStorage.
Due to this, the methodology of backing up virtual machines through vStorage is very different to that of VCB, and as such generated an error for each of my virtual machines during backup:
The virtual machine has a physical disk error (V-79-57344-38297), as shown in the above screenshot, was being reported for each virtual machine that has a Raw Device Mapping. In order to resolve this issue each Raw Device Mapping had to be changed from physical mode to virtual mode. The following actions were performed to achieve this:
1. Log into VMware vCenter as an administrative user.
2. Locate an affected virtual machine and safely power it down.
3. Right click on the virtual machine and select “Edit Settings”.
4. Locate the virtual hard disk drive that has been configured as a Raw Device Mapping.
5. Click remove and then when prompted select to delete the file. Please note this does not remove the data stored on your SAN LUN, this is simply a reference file used by the virtual machine itself.
6. Click OK, and wait for the Raw Device Mapping to be removed.
7. Right click on the virtual machine and select “Edit Settings”, select Add, and then select Hard Disk. Following the wizard, re-add your LUN or LUN’s and ensure that you set the compatibility mode to virtual and not physical.
8. Repeat for all affected virtual machines, and your all done!
For reference here’s VMware’s KB article on switching between RDM physical and virtual modes: http://kb.vmware.com/kb/1006599
