ROBOCOPY Backup files over Network paths and ERROR 5 (0x00000005) Copying NTFS Security to Destination Directory-Access denied

As part of the annual EPM DR Rehearsal, we got a requirement to move Prod Application backup files from PROD Network location to DR network path.

In this post, we will see how we can RoboCopy EPM backup files from one Network location to another network path.

Why ROBOCOPY?

If you are copying files from one network path to another and you have Windows Vista or later operating systems then Robocopy is a better choice than any other option. Because you don't need to bother with drive mappings, since it handles UNC paths just fine.

Robocopy is not a third party software. It's native (built-in) to all versions of Windows Vista and later.

It is usually far more reliable than xcopy command, and provides a lot more options.

Robocopy is tolerant of interrupts during copying i.e. it can pick up where it left off if it gets stopped for some reason. It has the ability to recover from certain types of network hiccups automatically.

Read Link1 and Link2 for more details about ROBOCOPY and its various options.

Script using ROBOCOPY to copy EPM backups from PROD to DR network path:

@echo off

for /f "delims=" %%a in ('wmic OS Get localdatetime ^| find "."') do set "dt=%%a"

::Format the WMIC command output in DDMMYYYY format

set "YY=%dt:~0,4%"

set "MM=%dt:~4,2%"

set "DD=%dt:~6,2%"

set "today_date=%DD%%MM%%YY%"

::Define Source path

set sourcepath1=\\PROD_Network_Share\data\EPM_Backups\%today_date%

set sourcepath2=\\PROD_Network_Share\data\EPM_Backups\DataZip

set sourcepath3=\\PROD_Network_Share\data\EPM_Backups\Scripts

::Define Destination path

set destinationpath1=\\DR_Network_Share\data\EPM_Backups_Copy\%today_date%

set destinationpath2=\\DR_Network_Share\data\EPM_Backups_Copy\DataZipCopy

set destinationpath3=\\DR_Network_Share\data\EPM_Backups_Copy\ScriptsCopy\%today_date%

::Define Log path

set logfile=E:\Admin\Prod_To_DR_Copy.log

::Run RoboCopy commands

REM Copy all the files, folders and sub-folders from source to destination

robocopy %sourcepath1% %destinationpath1% /E /COPY:DAT /NP /LOG+:"%logfile%"

REM Copy today'sdate(DDMMYY).zip file from source to destination

robocopy %sourcepath2% %destinationpath2% %today_date%.zip /COPY:DAT /NP /LOG+:"%logfile%"

REM Copy all the files with extensions .sh, .mxl, .ksh, .scr from source to destination

robocopy %sourcepath3% %destinationpath3% *.sh *.mxl *.ksh *.scr /COPY:DAT /NP /LOG+:"%logfile%"

Below is what each ROBOCOPY command options used above means:

• /E = Copy files including subfolders (even empty ones)
• /COPY:copyflag[s] = what to COPY for files. Here we have selected DAT: D=Data, A=Attributes, T=Timestamps 
• /NP = No Progress - don’t display % copied text in logfile; this keeps filesize down. 
• /LOG+:logfile = Output status to LOG file (+= append to existing log).

ERROR 5 (0x00000005) Copying NTFS Security to Destination Directory. Access denied

When I was trying to figure out the right set of options for ROBOCOPY command, I encountered this error multiple times.

This error is usually caused by RoboCopy trying to copy the security settings of the files, and this causes some mismatch regarding the file permissions. 

There is a /B switch in RoboCopy for copying in backup mode but Backup mode cannot circumvent explicit NTFS deny ACL’s if the copier isn’t the objects’ owner.

Solution: Use /COPY:DAT only

Option /COPY:copyflag[s] can take multiple values based on what you want to copy for files. To Copy ALL file info (equivalent to /COPY:DATSOU), there is an option /COPYALL.

To overcome the above-mentioned error, you should use /COPY:DAT instead of the /COPYALL option, because /COPY:DAT  ignores the NTFS access control lists (the COPY:S parameter) of the files you're copying. 

This works because /COPYALL is equivalent to /COPY:DATSOU, D=Data, A=Attributes, T=Timestamps, S=Security=NTFS ACLs, O=Owner info, U=aUditing info. While we mainly need Data and Timestamps of the files for EPM backups.

That's all for this post.

I hope this article has helped you. 

Your suggestions/feedback are most welcome.

Keep learning and Have a great day!!!

Read More

Send PowerShell email from Windows batch file without creating separate email.ps1 file

In this article, we will see how we can send a PowerShell email from the Windows batch file without creating any separate email.ps1 file.

Suppose you have a batch script to perform a certain task and once that task is completed you want to be notified through an email alert.

One way to achieve this is by creating a separate email.ps1 file and calling that email.ps1 from your batch file. You can find multiple solutions on Google for this approach. But if the purpose is just to send an email alert with an attachment like a log file or with some text in the email body then why to go for creating another email.ps1 file.

You can simply insert the below code at the end of your batch script or with some conditional statements to send an email alert within the batch script:

:: Send Email using PowerShell

Powershell.exe -command "& {Send-MailMessage -From Admin@company.com -To users@company.com -Subject 'Prod Hyperion Backup Copy to DR for DR Rehearsal' -SmtpServer 'smtpserver.company.com' -Body 'PFA log file consisting of details of PROD Hyperion Backup files copied to DR Network path' -Attachments 'E:\Data\Prod_DR_Copy.log'}"

Here:

• '&' is the call operator. The call operator (&) allows you to execute a command, script, or function.
• Change the parameter values (To, From, Subject, Body, SmtpServer, Attachments) as per your requirement.  

There are many other parameters that you can add to the above command as per your need. Read this Link1 and Link2 for more details.

Make sure you copy and paste the above code as it is. Because on some occasions, I have noticed that using double quotes ("") in place of single quotes ('') will throw PowerShell error:

Send-MailMessage :  A positional parameter cannot be found that accepts arguement "SomeWord"...

It happens because the PowerShell command processor strips your double quotes and your "SomeWord" appears as a parameter to Send-MailMessage. So to avoid this error, you need to escape double quotes in your command.

The best way is to use single quotes ('') in your command as given above but If you really want to use double quotes for whatsoever reason, then use it like below by escaping double quotes ("") in -Subject and -Body parameters:

Powershell.exe -command "& {Send-MailMessage -From Admin@company.com -To users@company.com -Subject \"Prod Hyperion Backup Copy to DR for DR Rehearsal\" -SmtpServer "smtpserver.company.com" -Body \"PFA log file consisting of details of PROD Hyperion Backup files copied to DR Network path\" -Attachments "E:\Data\Prod_DR_Copy.log"}"

That's all for this post.

I hope this article has helped you. 

Your suggestions/feedback are most welcome.

Keep learning and Have a great day!!!

Read More

EPM 11.1.2.4: Microsoft Edge and Google Chrome browsers support patching : Part-1

Note: This is Part-1 of 'Google Chrome and Microsoft Edge Browser Support' patching blogs . You can read Part-2 here.

In April 2020, one of our clients (on EPM 11.1.2.4) informed us that effective immediately, their IT team would begin supporting Microsoft’s new Edge* web browser making it the default browser on user machines. Users were recommended to use Edge for day-to-day browser activities. However, they did mention that there are several apps that are not yet compatible. So if you use one of those apps that have known compatibility issues, then you can continue using Internet Explorer (IE11) in these cases.

*Microsoft Edge is based on the Chromium open-source engine, just like Chrome. Compared to IE, with Edge, you can look forward to significantly faster browsing performance and compatibility, better overall security, and a slew of helpful new features.

We checked the EPM 11.1.2.4 certification matrix and informed the client that currently (as of May 2020), Google Chrome and Microsoft Edge Browsers are not supported by all the EPM applications so we should use IE11 only to smoothly access all the Hyperion apps.

But this whole picture got changed when in June 2020, Oracle notified that Google Chrome and Microsoft Edge Browser Support has been added to Enterprise Performance Management (EPM) 11.1.2.4 (click here to read).

Oracle updated the EPM 11.1.2.4 certification matrix to reflect the new changes, as shown below:

In order to make your EPM 11.1.2.4 environment compatible with Google Chrome and Microsoft Edge Browsers, you must update to the following supported releases:

• Hyperion Shared Services 11.1.2.4.100+ (Patch 31319089. Use Patch 31574562 for release 11.1.2.4.9xx) 
• Hyperion Planning, Hyperion Capital Asset Planning, Hyperion Workforce Planning, Hyperion Project Financial Planning 11.1.2.4.009+ (Patch 29889455) 
• Hyperion Calculation Manager 11.1.2.4.014+ (Patch 28557058) 
• Hyperion Financial Reporting 11.1.2.4.712+ (Patch 30670918. Use Patch 30671119 for release 11.1.2.4.9xx) 
• Hyperion Financial Management 11.1.2.4.208+ (Patch 28511735) 
• Hyperion Financial Close Management and Hyperion Tax Governance 11.1.2.4.253+ (Patch 29060830) 
• Hyperion Tax Provision 11.1.2.4.202+ (Patch 25316913) 
• Hyperion Financial Data Management 11.1.2.4.220+ (Patch 25312033) 
• Hyperion Profitability and Cost Management 11.1.2.4.130+ (Patch 29461894) 
• Hyperion Workspace 11.1.2.4.825+ (Patch 31124100. Use Patch 31486872 for release 11.1.2.4.9xx) 
• Hyperion Data Relationship Management 11.1.2.4.350+ (Patch 31420887)
• Additionally, you must also update Oracle JDeveloper / Application Development Framework 11.1.1.7.1 (Patch 31246831).

EXCEPTIONS

• Oracle JDeveloper / Application Development Framework does not apply to Hyperion Data Relationship Management or Hyperion Workspace.

For more information, read the following knowledge article: Browser Support Added for Google Chrome and Microsoft Edge with EPM System Releases Beginning with Release 11.1.2.4 - Doc ID 2675883.1

So we planned to apply these compatibility patches in our EPM 11.1.2.4 environment starting with DEV to make it work with Google Chrome and Microsoft Edge browsers.

As an obvious next step, we started looking for known issues/errors faced by any users after applying these compatibility patches.

Then we came to know about one technical issue reported as Hyperion Shared Services not working in Google Chrome and Microsoft Edge (Doc ID 2698535.1).

Notably, as per the Doc ID 2698535.1, this issue is reported not only in EPM 11.1.2.4 but also in the very latest EPM 11.2.1 and EPM 11.2.2 releases (Let me know in the comment section if you have a functional EPM 11.2.1 or 11.2.2 environment and face this issue on Microsoft Edge or Google Chrome browser.) 

As per Doc ID 2698535.1, after applying these compatibility patches mentioned in Doc ID 2675883.1, from Shared Services Console, attempting the following tasks results in an "empty" grey screen or grey pop-up:

• create new Native User
• provision existing user
• LCM import/export
• Migration Status Report

In short, you will be having issues while using Hyperion Shared Services Console on Google Chrome or Microsoft Edge browsers post applying these patches.

Oracle has already raised two bugs for this problem as mentioned in Doc ID 2698535.1:

1. Unpublished bug created for 11.1.2.4 Bug 31686588
2. Unpublished bug created for 11.2.1 Bug 31546643

As a workaround for this issue in Hyperion Shared Services console, the following is suggested in Doc ID 2698535.1:

• For 11.1.2.4, workaround is to use Internet Explorer 11.x or Firefox 31+ ESR
• For 11.2.1, workaround is to use Internet Explorer 11.x or Firefox ESR
• For 11.2.2, workaround is to use Firefox ESR 

We decided to first clear the air about this compatibility patches and reported bugs before we patch our systems.

To that effect, we recently had a call with Oracle, and below is what we can summarize based on our discussion:

As far as these two bugs are concerned, there is still no solution provided for EPM 11.1.2.4, EPM 11.2.1, or EPM 11.2.2. Most probably, these bugs will be fixed in the EPM 11.2.3 release (as of Oct 2020). 

For EPM 11.1.2.4, you should go-ahead and patch your EPM 11.1.2.4 environment with these compatibility patches. As post patching there will be no impact on EPM 11.2.4 functioning with IE11 browser i.e. all the features/functionalities will continue to work fine on IE11 browser regardless of whether you have applied the new compatibility patches or not to make your EPM 11.2.4 environment compatible with Google Chrome and Microsoft Edge.

Post compatibility patching, the reported issue of "empty" grey screen in Doc ID 2698535.1 is limited to Hyperion Shared Services Console only for the tasks like create new Native User, provision existing user, LCM import/export, Migration Status Report. Other functionalities/features/consoles in EPM 11.1.2.4 work fine on Google Chrome and Microsoft Edge browsers. 

For the end-users, there are hardly any issues because Hyperion Shared services Console is mostly used by Hyperion Admins for user management and LCM related tasks.

The above summary gives a sense of security that at least there is nothing to lose after applying these compatibility patches mentioned in Doc ID 2675883.1 in your EPM 11.1.2.4 environment. After applying these patches in your EPM 11.1.2.4 environment, you can use:

• Google Chrome or Microsoft Edge browser for all the activities except on Hyperion Shared Services console
• IE11 for Hyperion Shared Services console activities only (mostly by Hyperion Admins)

As for the client, upgrading the current EPM version 11.1.2.4 to EPM 11.2 is still a good 6 months away (as of Oct 2020) and their IT team has already made Microsoft Edge the default browser, we are going to apply these compatibility patches in our 11.1.2.4 DEV environment for Microsoft Edge and Google Chrome compatibility. 

That's all for this post. 

I hope this article has helped you. 

Your suggestions/feedback are most welcome.

Keep learning and Have a great day!!!

Read More

FDMEE 11.1.2.4.220: Essbase Export data file has changed naming convention

It has not been long since we applied FDMEE (Financial Data Quality Management, Enterprise Edition) Patch Set Update 11.1.2.4.220 (Patch 25312033) in one of our TEST environments. Earlier it was on version FDMEE 11.1.2.4.210. The patch got successfully applied but during environment validation, we observed that for data load to Essbase target applications, the data export files (.dat) coming into the FDMEE outbox folder have changed its naming convention. 

This naming convention change is there only for Hyperion Essbase data files. HFM (Hyperion Financial Management) application data files continue to be using the same old naming convention. 

On investigation, we noticed it's happening exactly after we applied FDMEE (Financial Data Quality Management, Enterprise Edition) PSU 11.1.2.4.220.

What is the issue?

Earlier, in FDMEE 11.1.2.4.210, for Essbase Target applications data load, the export data file names were in the format: 

<Essbase Application Name>_<Process ID>.dat. 

But now in FDMEE 11.1.2.4.220, the data file naming convention has changed to the format: 

<Essbase Application Name>-<Essbase Database Name>_<Process ID>.dat

We see Essbase Database Name has been added with Essbase Application Name in the .dat file name.

You can see below how all the Essbase export .dat files had started to generate with the new naming format after a particular date:

This was also confirmed by comparing the data load process logs of FDMEE 11.1.2.4.220 and 11.1.2.4.210 for the same FDMEE Location or Essbase target application, as shown below:

FDMEE 11.1.2.4.210 process log:

FDMEE 11.1.2.4.220 process log:

What is the impact?

This naming convention change for Essbase target applications had broken one of our automation processes for Essbase application data load. One impacted script identified was AftLoad.py which was called after the data is loaded to the Essbase target application. In that script, it was hardcoded to read the generated data file in format <Essbase Application Name>_<Process ID>.dat.

Investigation?

As per Oracle documentation, we know that data is written to a data file in the outbox directory of the application (defined in System Settings) in the format <APPLICATION NAME>_<PROCESS ID>.dat. It is then loaded to your Essbase target applications. 

Details of our target applications (Data Management > Setup > Register > Target Application) are stored in AIF_TARGET_APPLICATIONS table in the FDMEE database. 

When we query this table for the below columns:

SELECT TARGET_APPLICATION_TYPE, TARGET_APPLICATION_NAME, ESSBASE_DB_NAME, APPLICATION_NAME FROM AIF_TARGET_APPLICATIONS WHERE TARGET_APPLICATION_TYPE = 'ESSBASE';

We get the following output:

Values in the three columns come as: 

• TARGET_APPLICATION_NAME  = Essbase Application Name
• ESSBASE_DB_NAME                    = Essbase Database Name
• APPLICATION_NAME                   = Essbase Application Name-Essbase Database Name

So apparently, to generate the Essbase export data file, FDMEE 11.1.2.4.220 is taking the value of column APPLICATION_NAME while FDMEE 11.1.2.4.210 was taking the value of column TARGET_APPLICATION_NAME. That's why the naming convention of Essbase export data files has been changed in FDMEE 11.1.2.4.220. 

HFM export data files names are unaffected because, for HFM, both APPLICATION_NAME and TARGET_APPLICATION_NAME columns values are the same as obvious:

What Oracle said?

We raised an Oracle SR and below is what they updated:

We have cross verified this with Product Development Manager and they said that this is an accepted behavior in FDMEE (Financial Data Quality Management, Enterprise Edition) 11.1.2.4.220 PSU as the Developer has changed the backend code for FDMEE functionality with Essbase. So you need to modify your automated scripts accordingly. 

So what is the workaround?

Well, as advised by Oracle we have modified our automated scripts like AftLoad.py and related batch scripts to incorporate the new naming convention of Essbase export data files. 

That's all for this post. 

I hope this article has helped you. 

Your suggestions/feedback are most welcome.

Keep learning and Have a great day!!!

Read More