3 days ago, on 13th October 2016, HPE has released patch bundle 9,08 for Data Protector 9. A patch bundle isn’t a directly installable version, instead it’s a bundle of patches and enhancements for a specific version of Data Protector, in this case Data Protector 9.
Beside fixes for discovered problems, a patch bundle includes also enhancements. There are some enhancements in this patch bundle, that have caught my attention particularly.
In my last post (Routed Port vs. Switch Virtual Interface (SVI)), I have mentioned a consequence of using routed ports to interconnect access and core switches:
You have to route the traffic on the access switches.
Routing on the network access, the edge of the network, is not a question of performance. It is more of a management issue. Depending on the size of your network, and the number of subnets, you have to deal with lots of routes. And think about the effort, if you add, change or remove subnets from your network. This is not what you want to do with static routes. You need a routing protocol.
Many years ago, networks consisted of repeaters, bridges and router. Switches are the successors of the bridges. A switch is nothing else than a multiport bridge, and a traditional switch doesn’t know how to pass traffic to a different broadcast domains (VLANs). Passing traffic between different broadcast domains, is a job for a router. A router has an IP interface in each broadcast domain, and the IP interface is used by the clients in the broadcast domain as a gateway.
Customers that use HPE 3PAR StoreServs with 3PAR OS 3.2.1 or 3.2.2 and VMware ESXi 5.5 U2 or later, might notice one or more of the following symptoms:
Lost access to volume
Recently, a customer has informed me, that copy sessions to encrypted devices failed, after he has made an update to Data Protector 9.07. The copy sessions failed with this error:
|Critical| From: BMA@<hostname> "" Time: <Date><Time>
|90:6111| Error retrieving encryption key.
The customer uses tape encryption. The destination for the backups is a HPE StoreOnce, and a post-backup copy creates a copy of the data on tape. Backup to disk was running fine, but the copy to tape failed immediately.
The Virtual Router Redundancy Protocol (VRRP) was developed in 1998 as an open standard protocol. VRRP is the result of an Internet Engineering Task Force (IETF), and it’s described in RFC 5798 (VRRPv3). VRRP was designed as an open standard protocol, but it uses some patents from Cisco. Its function is comparable to Cisco Hot Standby Router Protocol (HSRP), or to the Common Address Redundancy Protocol (CARP). VRRP solves a very specific problem at the network edge: It offers highly available virtual router interfaces, or in simple words: A highly available default gateway. Its home is the network edge, and because of this, VRRP is a so called first hop redundancy protocol. When moving towards network core, VRRP loses importance. If you move from the network edge to the core, redundancy is primarily offered by dynamic routing protocols and redundant links.
Sometimes you have to check when the last backup of an Exchange mailbox database was taken. This is pretty simple, because the timestamps of the last full, incremental and differential backup is stored for each mailbox database. You can check these attributes using the Exchange Control Panel (ECP), or you can use the Get-MailboxDatabase cmdlet.
Take a look at this output. As you can see, there’s no timestamp for the last full, incremental and differential backup. But this database was successfully backuped some minutes before.
When you use Microsoft Outlook in cached mode, what I always recommend, and you add additional mailboxes to your outlook profile, you will notice that the OST file will grow. Outlook will download the mailbox items (mails, calendar entries, contacts etc.), and store them in the OST file. This is the default behaviour since Microsoft Outlook 2010. If you want to disable this behaviour, you have two options:
The easiest way is to use a reg file. Copy this text into a file and save it as disablecachedmode.reg. Then double click the file and confirm, that you want to import the registry file.
Edit: If you have already installed .NET 4.6.1, check this blog post on how to remove it (You Had Me At EHLO…)
Microsoft Exchange heavily relies on Microsoft .NET Framework. Because of this, Microsoft provides a matrix for the supported Microsoft .NET Frameworks. Mostly unknown is the fact, that Exchange doesn’t support the every Microsoft .NET Framework, and this is causing trouble sometimes. Some admins simply install the latest .NET releases because “it doesn’t hurt”. Well… it hurts!
After deploying a new Microsoft Exchange organization with Exchange 2016, or after deploying a Microsoft Exchange 2016 into an existing organization, you might notice a strange behaviour regarding the Offline Address Books (OAB).
[PS] C:\Windows\system32>Get-OfflineAddressBook
Name Versions AddressLists
---- -------- ------------
Standard-Offlineadressliste {Version2, Version3, Version4} {\Globale Standardadressliste}
Standard-Offlineadressliste (Ex2013) {Version4} {\Globale Standardadressliste}
Huh?! Where does this Exchange 2013 OAB come from? As you can see in the cmdlet output, there’s no Exchange 2013 in this organization.