Thursday, May 9, 2019

Symantec/VERITAS Scheduled Data Restore Test From Backup


Data is the most valuable asset of any industry and Information technology stores data in digital form with the help of computer hardware’s and software’s.  The computer system can fail and result data loss.

We protect digital data stored in computer hardware’s using backup software, also follow the practice performing test restores of files & folders from the data being backed up.

Doing manual test restore of data is time consuming and again a pain if you have backup solutions from different vendors is being used in your IT infrastructure.

Here we are going to see how to automate the test restore of data from backup using Powershell.

The Script can be used to automate file/folder restore test from the Symantec/VERITAS backup. Restore test is to ensure that the data is recoverable from the backup.

Pre-requisites


1. Windows Powershell version 4.0 or above
2. Ensure that BEMCLI or Backup Exec powershell module installed in your backup server.
To ensure open an administrative powershell and run below commands.
PS C: \windows\system32> Import-Module -name BEMCLI PS C: \windows\system32> Get-command -name BEMCLI
3. Ensure that the user account used to schedule the script must have necessary permissions to restore the files and folders, also should have access to Symantec/VERITAS registry locations.
4. Configure the below on Symantec/VERITAS backup exec console to get an additional alert about job restoration status.
a) Login to BE console --> click on the yellow database icon (for VERITAS – red play icon) on top left side --> Configuration and Settings --> Alerts and notifications --> Email alert and text notification


b) Under Email configuration enter the details of Email Server and Port, Sender name, Sender email address, also enter credentials if your email server requires authentication.























c) Navigate --> click on the yellow database icon (for VERITAS – red play icon) on top left side --> Configuration and Settings --> Alerts and notifications --> Notification recipient --> click add recipient and enter the recipient name and email address --> check the tick box send email notification by email.

d) Click on send test email to verify the alert notification is received to the inbox of configured email recipient.
5. Verify the name of server or servers in the Backup exec console those are selected for restore test.
6.Create a folder named “BackupTest” in the C or D drive of servers chosen for restore test and add some files into it.(Total size of all files in the folder should be greater than 1 MB)
7. By verifying the backup job report ensures that the folder is being backed up in the last backup schedule.
8. Create a folder named “BackupRestoreTest” on the D or any drive of the backup exec server.




How to use the PowerShell Script


STEP 1) Download the script “BE-Restore.ps1” from the GitHub and extract it to any drive.










STEP 2) Edit the following portion in the script.
#Edit this session

#The folder chosen for test restore from the server.

$Foldername = "D:\BackupTest"

#The Server chosen for test restore

$Server = "Server01"

Note: Ensure that server name should be exact match with the name shown in the backup exec console.

Example: “Server01” or Server01.sjohnonline.in

#Data restore path

#Note: If admin shares(d$ c$) are disabled in your machine create a share in the backup server and use the share path "\\backupexecserver\sharename\$today"

#Enabling admin shares may increase the chances of attack surfaces


$Restorepath = "\\backupexecserver\d$\BackupRestoreTest\$today" #Keep $today(variable)

#Recipient name configured in the alert notification on backup exec console.

$recipient = "Sijo John"

#Email address of sender

$FromAddress = "BErestoretest@sjohnonline.in"

#Email address of recipient

$ToAddress = "sjohn@sjohnonline.in"

#Subject of the email

$Subject = "Symantec/VERITAS backup exec Monthly scheduled backup-Restore Test"

#SMTP Server responsible for email service

$SMTPServer = "Enter SMTP server name or IP here"


#SMTP Server port number

$SMTPPort = “Enter the SMTP port number”

STEP 3) Open a PowerShell (Administrative PS recommended)
STEP 4) Navigate and set path to script root folder
Example: PS D:\Symantec-VERITAS-Data-Restore>
STEP 5) Run the script --> PS D:\Symantec-VERITAS-Data-Restore> .\BE-Restore.ps1
SETP 6) Script creates a new folder named “present date” under the restore path specified and restores the files & folders into it. Also you will get an email notification from backup exec console about the restoration job status.
Example: 05-05-2019




STEP 7) upon completion of restore operation, the script verifies the file restored and notify if the folder is empty or not. If folder is empty “restore failed”.
STEP 8) Logging is enabled on the script for troubleshooting, check “logs” folder under the script root folder if you come across any errors.
Example: D:\Symantec-VERITAS-Data-Restore>\logs



STEP 9) The log will be attached and send to the recipient email address with following information
Restore test performed on Server = Server01
Restored folder = D:\BackupTest
Restore path = \backupexecserver\d$\BackupRestoreTest\07052019
Restore start time = 05/07/2019 15:05:36
Restore end time = 05/07/2019 15:05:36
Size of data restored in MB = 9.35 MB
Restore status = Success
STEP 10) Information in the Log file helps to analyze the estimated time requirement for data restore.

STEP 11) The script can be schedule using task scheduler to perform restore tests from backup as per the requirement.

Troubleshooting

1. Logging is enabled on the script with run time, date and year, check the folder "logs"

Future Enhancements

1. Expand functionality for Veeam and Microsoft Azure backup.

Backup Exec version Tested

Support all versions of Symantec/VERITAS Backup-exec
1)Symantec Backup Exec 2014
2)Symantec Backup Exec 2015
3)VERITAS Backup Exec 2016
4)Symantec Backup Exec 2020

Hope this article is helpful saving your time.

Cheers 👍
Sijo John

Friday, May 3, 2019

Network Switch Firmware Upgrade Best Practices


Network Switch Firmware Upgrade Best Practices.


Hello Everyone, In this session i would like to brief about some best practices to be followed while upgrade your network switch firmware version.

Firmware is software that is embedded into a hardware device. Firmware controls how your device behaves. New firmware often fixes bugs, contains new features, and protects you from security vulnerabilities.

Some times switch firmware upgrade end up with a disaster and a pain if it is a Core switch😟 
 
The below steps would give you some inputs into your implementation plans for a switch firmware upgrade even though it is only a brief note.

Always consider your Network infrastructure and merge these practices with your plan which may help you to perform smooth upgrade.

Pre-requisites

      1)  Check the current firmware version on primary and secondary flash.

            Ex : 5406-CORE Chassis: 5406zl J8697A!
             Serial Number: XXXXXXX
             Primary Image: 14151077 03/08/11 K.15.04.0003
             Secondary Image: 9782454 07/07/09 K.14.34
             Current ROM version: K.15.12
             Switch Modules: J9309A, J8702A, J9308A, J9308A, J9309A

2)  Verify core switch architecture (Standalone or VRRP/HSRP/VSF)

3)  Check for firmware upgrade path (If firmware is too old get help from vendor to get a correct upgrade path)

4)  If firmware is too old vendors recommend for staged upgrade.

5)  Select the firmware upgrade path, read the release notes carefully and ensure that all firmware versions in the path are compatible with the Hardware, Rom version, Modules (including management module) and commands of the Switch.

6)   Release notes of respective firmware versions can be downloaded from the vendor’s website.

7)  Download the required firmware versions from vendor’s website.

8)  Ensure the availability of spare serial console cable, laptop, internet connection and necessary software’s (Putty, Teradem, Xmodem) to connect and configure the core switch in case of any failure.

9)   Ensure that the availability of uninterrupted power supply to avoid damage to your equipment, during the software update.

10)  Take a valid recent running and start-up configuration backup of switch before the upgrade.

11)  If the switch have 2 flashes,  primary flash and configuration should be copied to secondary flash before the upgrade, So in case of any issues, switch can be boot from secondary flash, which is having current version of the firmware and configuration. 


      The below steps are for your reference
       

      HP modular 5406zl core switch upgrade


1)   Start a portable TFTP server.

2)  Save your current configuration (Config1) to a backup configuration file (Config2).

       Switch# show version
 Switch1# copy config config1 config config2
 Switch1# show config files 

3) Take a backup of configurations (Start-up and Running) after saving the running configuration

 Switch# copy running-configtftp
 Switch# Write memory
 Switch# copy startup-configtftp 

4)  Backup your current running image (Primary) to the secondary image.

Switch1# copy flash flash secondary
Switch1# show flash 

5)  Set your secondary image to boot with Config2. 

Switch1# startup-default secondary config config2
Switch1# show config files

6) Verify that your images and configuration are set correctly

Show flash
Show config files
Show version

7) Rename the downloaded firmware to K.15.10.0019m.swi and copy it to the tftp root folder
 
8) Copy the new flash from tftp server to the switch Command line

Switch# copy tftp flash K.15.10.0019m.swi Primary

Give yes to the prompt appeared The Primary OS image will be deleted. Continue [y/n]? Y

Note: When the switch finishes downloading the software file from the server, it displays the progress message Validating and Writing System Software to FLASH...

9) When the CLI prompt re-appears, the switch is ready to reboot to activate the downloaded software Type the command Show flash to verify that the new software version is in the expected flash area (primary or secondary)

10) Reboot the switch from the flash area that holds the new software (primary or secondary), using the following command: 

Switch# boot system flash primary
If this do not work try from (config)#

11) Leave the secondary image untouched, this can be update later. The rollback plan is to boot switch from secondary flash and its configuration in case of  any issues while running from primary image.

12) Take a backup of switch configurations and upload it to a secure location.

13)  If you have HSP/VRRP/VSF redundant switch architecture, repeat the steps 7-9 & 11 for firmware upgrade on other peer switches.

14)   Repeat all the above steps for continuing the firmware upgrade as mentioned in the upgrade path. (In case your firmware version is too old)

Ex: Current Firmware version: K.15.04.0003
Upgrade path:  K.15.10.0019m ----> K.15.15.0014 ----> K.15.18.0018 ---> K.16.02.0022m.

Post Upgrade Checks



1) Login to the switch via Putty

2) Check the firmware versions by issuing the following command

Switch# Show flash
Switch# Show Version
Switch# Show config files

3) Verify the event logs for any critical alerts

Switch# show logging –r

4) Verify the running configuration

Switch# Show running-configuration

5) Compare the new and old configuration files

Rollback Plan


1) Boot from the secondary image by issuing the command

 switch# boot system flash secondary

2) In case of network connectivity issues, use the serial cable to connect to the switch and boot the switch from Secondary flash.
3) Restore the configuration from backup if identified any issues with the start-up or running configurations.

Using SSH Connection

Switch# copy tftp startup-config .

If network connection is available use serial console and Xmodem via Hyperterminal to access the switch

 a) Switch#copy startup-configxmodem pc

b) Then hit the enter key, there will be a warning device require a reboot, then select Y

c) Click on the Transfer menu and then select Send File

d) Browse and navigate to the file that will be used for restoring

e) On the protocol, select xmodem and then click Send.

f) The switch then will restart automatically.

g) To see the new configuration in the switch, login again, and type: show run then hit Enter key.



Hope it is informative for you, in the coming session we will see how to automate the switch firmware upgrade using windows power-shell and SSH.

Cheers
Sijo John







   

Saturday, February 16, 2019

Skype For Business Online - Signal and Media Traffic Flow - Office LAN - WAN Users



Skype For Business Online - Signal and Media Traffic Flow


Hope you have already gone through my blog about types of traffic and protocols used in Skype for business.

If not, here is the link to have a look https://sjohnonline.blogspot.com/2018/12/skype-for-business-online-types-of.html.

In this article we will see the signal and media traffic flow when users communicate from office LAN and internet.

Traffic flow is very similar to the communication happens between 2 internet users but just thought of explain the same scenario with respect to the office LAN network instead of the home network.

Skype signalling and media traffic flow between Office LAN and WAN users



Skype uses ICE protocol to establish the communication between peers, let me take you through the  process happening in the background.

Step 1 SIP Registration and Candidate discovery


SIP Signalling initiate user authentication and registration with MRAS server in O365 cloud and identify the IP addresses, ports and protocols used by caller, in our case caller is user01

Step 2 invitation with SDP Candidates of caller.


User01 invites user02 by sharing the details of IP addresses, ports and protocols used by user01.

Step 3 Invitation acceptance with SDP Candidates of callee


User02 accept the invitation and share the details of IP addresses, ports and protocols used by user02 with user01.

During this time caller can hear the ring tone which indicates that the connection establishment is in progress.

Step 4 Candidate exchange and connectivity check (Candidate validation)


Caller and callee exchange their IP addresses and ports details with each other and try to check connectivity between the users via all possible routes available.

In our case the details of Candidate is as follows (Candidate - IP addresses, and ports).

 User01 

Local IP address - 192.168.10.44

NAT IP address/Public IP - 106.203.110.116 (Also called as reflex IP address)

Relay server IP address - 131.253.138.142 (Also called as relay IP address)


User02

Local IP address - 172.16.18.254

NAT IP address/Public IP - 185.55.61.182 Also called as reflex IP address)

Relay server IP address - 52.112.132.189 (Also called as relay IP address)


Here the reflex IP addresses (NAT IP's) are not same for both users and cannot communicate with each other using LAN IP address.

Connectivity checks are performed to find out the most direct media path possible between endpoints using STUN protocol.

As UDP is preferred for audio/video communication, the connectivity checks start with UDP 

a) First try to check connectivity between local IP's 192.168.10.44 & 172.16.18.254 over UDP

b) Then try to check connectivity between reflex IP's 106.203.110.116 & 185.55.61.182  over UDP

c) Finally try to check connectivity between relay IP's  131.253.138.142 & 52.112.132.189 over UDP

d) If all the above checks failed then start the connectivity check using TCP.

Step 5 Connection establishment 


After the connectivity checks, STUN protocol will evaluate the routes identified and find out most direct route to establish connection between the users.

In this scenario connection establishment between users are not possible be via local IP's 192.168.10.44 & 172.16.18.254  as both users are under a NAT device

Since the clients are behind a NAT device direct communication may fails and connection established using Reflex IP addresses 106.203.110.116 & 185.55.61.182 (NAT IP or Public IP).

As mentioned if none of the above connectivity method is possible, connection will be established using the relay server in O365 cloud and which may effect quality of communication.

In this scenario the Quality of service cannot be guaranteed 100% as the traffic flows through internet and it is not a network managed by us but we could try apply the QoS as per the standards in-order to get better results.

Always follow and implement Skype network requirement best practices in your network and open necessary ports and protocols in the firewalls to get the good quality communication.


Hope this is informative for you.

Cheers 😊





Wednesday, February 6, 2019

Skype For Business Online - Signal and Media Traffic Flow - WAN Users (Internet)



Skype For Business Online - Signal and Media Traffic Flow


Hope you have already gone through my blog about types of traffic and protocols used in Skype for business.

If not, here is the link to have a look https://sjohnonline.blogspot.com/2018/12/skype-for-business-online-types-of.html.

The previous article was about the Skype for business traffic flow between LAN Users

https://sjohnonline.blogspot.com/2018/12/skype-for-business-online-signal-and.html

In this session we will see the signal and media traffic flow when users communicate from different internet networks.

Skype signalling and media traffic flow between WAN users



Skype uses ICE protocol to establish the communication between peers, let me take you through the  process happening in the background.

Step 1 SIP Registration and Candidate discovery


SIP Signalling initiate user authentication and registration with MRAS server in O365 cloud and identify the IP addresses, ports and protocols used by caller, in our case caller is user01

Step 2 invitation with SDP Candidates of caller.


User01 invites user02 by sharing the details of IP addresses, ports and protocols used by user01.

Step 3 Invitation acceptance with SDP Candidates of callee


User02 accept the invitation and share the details of IP addresses, ports and protocols used by user02 with user01.

During this time caller can hear the ring tone which indicates that the connection establishment is in progress.

Step 4 Candidate exchange and connectivity check (Candidate validation)


Caller and callee exchange their IP addresses and ports details with each other and try to check connectivity between the users via all possible routes available.

In our case the details of Candidate is as follows (Candidate - IP addresses, and ports).

 User01 

Local IP address - 192.168.1.10

NAT IP address/Public IP - 43.71.140.7  (Also called as reflex IP address)

Relay server IP address - 52.112.89.78 (Also called as relay IP address)


User02

Local IP address - 192.168.0.2

NAT IP address/Public IP - 108.7.56.72 Also called as reflex IP address)

Relay server IP address - 52.112.74.66 (Also called as relay IP address)


Here the reflex IP addresses (NAT IP's) are not same for both users and cannot communicate with each other using LAN IP address.

Connectivity checks are performed to find out the most direct media path possible between endpoints using STUN protocol.

As UDP is preferred for audio/video communication, the connectivity checks start with UDP 

a) First try to check connectivity between local IP's 192.168.1.10 & 192.168.0.2 over UDP

b) Then try to check connectivity between reflex IP's 43.71.140.7 & 108.7.56.72  over UDP

c) Finally try to check connectivity between relay IP's  52.112.89.78 & 52.112.74.66 over UDP

d) If all the above checks failed then start the connectivity check using TCP.

Step 5 Connection establishment 


After the connectivity checks, STUN protocol will evaluate the routes identified and find out most direct route to establish connection between the users.

In this scenario connection establishment between users are not possible be via local IP's 192.168.1.10 & 192.168.0.2  as both users are under a NAT device

Since the clients are behind a NAT device direct communication may fails and connection established using Reflex IP addresses 43.71.140.7 & 108.7.56.72(NAT IP or Public IP).

As mentioned if none of the above connectivity method is possible, connection will be established using the relay server in O365 cloud and which may effect quality of communication.

In this scenario the Quality of service cannot be guaranteed 100% as the traffic flows through internet and it is not a network managed by us but we could try apply the QoS as per the standards in-order to get better results.

Always follow and implement Skype network requirement best practices in your network and open necessary ports and protocols in the firewalls to get the good quality communication.


Hope this is informative for you.

Cheers 😊