GPO – Deploying Java 8 Update 60

Extracting the MSI

To extract the MSI, run the “jre-8u60-windows-i586.exe” or  “jre-8u60-windows-x64.exe” EXE do not proceed with the installation. Open the folder “%LOCALAPPDATA%Low\Oracle\Java”, depending if you ran the i586 or x64 version you will see one of the following folders.

• jre1.8.0_60
• jre1.8.0_60_x64

Open up the correct folder, and within the folder you will see the MSI file “jre1.8.0_60.msi”. Copy this MSI to another location then cancel the installation.

Silent Install Error

Now that you have the MSI file you have probably tried to install it from the command line using “msiexec /qb /i jre1.8.0_60.msi”. If you used a command prompt that isn’t elevated you get the following error in the event viewer, even though you elevate the MSI installation.

“Error 1722. There is a problem with this Windows Installer package. A program run as part of the setup did not finish as expected. Contact your support personnel or package vendor.”

MSI Fixes

The reason for the error above is that the MSI executes an installer that is embedded into the MSI, but when it runs this installer it doesn’t run it with administrative privileges instead it runs it in the logged on users security context. To fix this you need to modify the MSI DB with an MSI DB editor such as Orca (My personal preference is InstED http://www.instedit.com/). Open the MSI in your editor of choice and open up the table “CustomAction” and select the row “installexe” and change the value of the field “Type” to decimal 3090 or hexadecimal 0x0C12. This will set the msidbCustomActionTypeNoImpersonate bit so that it runs the embedded installer with administrative privileges.
Once the change above has been made the installer will now fail with the following error.

“Unable to install Java. Unable to open file C:\ProgramData\Oracle\Java\java.settings.cfg. Check that the configuration file exists and that the path to the file is correct.”

To fix this error an empty configuration file “java.settings.cfg” needs to be added to the “%ALLUSERSPROFILE%\Oracle\Java” folder by the installer. To do this we need to add 6 new entries to various tables in the MSI DB.
Once again open the MSI in your editor of choice and perform the following:

1. Insert a new row into the table “Directory”
   • Directory Field = CommonAppDataFolder
   • Directory_Parent Field = TARGETDIR
   • DefaultDir Field = .:Common~1|CommonAppData
2. Insert a new row into the table “Directory”
   • Directory Field = OracleDir
   • Directory_Parent Field = CommonAppDataFolder
   • DefaultDir Field = Oracle
3. Insert a new row into the table “Directory”
   • Directory Field = JavaDir
   • Directory_Parent Field = OracleDir
   • DefaultDir Field = Java
4. Insert a new row into the table “Component”
   • Component Field = emptycfgComponent
   • ComponentId Field =
   • Directory_  Field = JavaDir
   • Attributes Field = Decimal 0 or Hexadecimal 0x0000
   • Condition Field =
   • KeyPath Field =
5. Insert a new row into the table “FeatureComponents”
   • Feature_ Field = jrecore
   • Component_ Field = emptycfgComponent
6. Insert a new row into the table “File”
   • File Field = java.settings.cfg
   • Component_ Field = emptycfgComponent
   • FileName Field = java~1.cfg|java.settings.cfg
   • FileSize Field = 0
   • Version Field =
   • Language Field =
   • Attributes Field = Decimal 8192 or Hexidecimal 0x2000
   • Sequence Field = 2
7. Insert a new row into the table “Media”
   • DiskId Field = 2
   • LastSequence Field = 2
   • DiskPrompt Field =
   • Cabinet Field =
   • VolumeLabel Field =
   • Source Field =
8. Insert a new row into the table “RemoveFile”
   • FileKey Field = java.settings.cfg
   • Component_ Field = emptycfgComponent
   • FileName Field = java~1.cfg|java.settings.cfg
   • DirProperty Field = JavaDir
   • InstallMode Field = 3

This adds a reference to the file in the installer DB, now you need to create an empty “java.settings.cfg” file. To do this open the folder where the MSI is located and create the folder structure “CommonAppData\Oracle\Java” and then within the “Java” folder create an empty file called “java.settings.cfg”.
The last thing to be done is to set the embedded installer so that it installs silently when the UI level is set to “Basic UI” (/qb switch) , the current configuration is that it only installs silently if the UI level is set to “No UI” (/qn switch). To change this open the MSI in your editor and open the table “InstallExecuteSequence”, within that table locate the action “SetSilentInstall” and change the condition from “UILevel=2” to “UILevel<=3”.
With the changes above you will find that the MSI installer should work as expected.

Customisations

There are many articles out on the web on how to customise the installation of Java 7 by changing/adding properties to the “Properties” table in the MSI, the same properties still apply. Here are the ones that I’ve chosen to set in our deployment.
Disable Java Auto Update

• AUTO_UPDATE=0
• AUTOUPDATECHECK=0
• JU=0
• JAVAUPDATE=0

Disable the EULA

• EULA=0

Disable the installation Java with sponsored software

• SPONSORS=0

Lower the web Java security level (Note: High is the lowest setting in Java 8)

• WEB_JAVA_SECURITY_LEVEL=H

Disable the sending of  installation-related statistics to Oracle

• WEB_ANALYTICS=0

Common DFSR Configuration Mistakes and Oversights

• Too small of a Staging Area Quota

Are you seeing a lot of event ID’s 4202 and 4204? If so, your staging area is not sized correctly. The downside to an improperly sized staging area is that replication performance will be negatively affected as the service has to spend time cleaning up the staging area instead of replicating files.
DFSR servers are more efficient with a full staging area for at least these two reasons:

1. It is much more efficient to stage a file once and send it to all downstream partners than to stage a file, replicate the file, purge for each downstream partner.
2. If at least one member is running Enterprise Edition the servers can take advantage of Cross File RDC

An improperly sized staging area can also cause a replication “loop” to occur. This condition happens when a file get replicated to the downstream server and is present in the staging however the file is purges by the staging area cleanup process before the file can be installed into the Replicated Folder. The purged file will be replicated again to the server that just purged it from its staging as it never got to install the file. This process will keep repeating until the file gets installed.
Don’t ignore staging area events.
See this blog post for the method to use to determine your minimum staging area size
See the section “Increase Staging Quota” here
See “Remote Differential Compression details” here for information on Cross File RDC

• Improper or Untested Pre-seeding procedure

Pre-seeding is the act of copying the data that will be replicated to a new replica member before they are added to the Replicated Folder with the goal of reducing the amount of time it takes to complete initial replication. Most failed pre-seeding cases I have worked on failed in 3 ways.

1. ACL mismatch between source and target.
2. Changes were made to the files after they were copied to the new member
3. No testing was done to verify the pre-seeding process they were using worked as expected.

In short the files must be copied in a certain way, you cannot change the files after they are staged and you must test your process.
Click here to read Mr. Pyle’s blog on how to properly pre-seed your DFSR servers

• High backlogs for extended periods of time

Besides the fact that having high backlogs for extended periods of time means your data is out of sync, it can lead to unwanted conflict resolution where a file with older content wins in a conflict resolution scenario. The most common way I have seen this condition hit is when rolling out new RF’s . Instead of doing a phased rollout some admins will add 20 new RF’s from 20 different branch offices at once overloading their hub server. Stagger your rollouts so that initial replication is finished in a reasonable amount of time.

• DFSR used as a backup solution

Believe it or not some admins run DFSR without backing up the replicated content offline. DFSR was not designed as a backup solution. One of DFSR’s design goals is to be part of an enterprise backup strategy in that it gets your geographically distributed data to a centralized site for backup, restore and archival. Multiple members do offer protection from server failure; however, this does not protect you from accidental deletions. To be fully protected you must backup your data.

• One way Replication – Using it, or Fixing One way replication the wrong way

In an attempt to prevent unwanted updates from occurring on servers where they know the data will never be changed (or they don’t want changes made there) many customers have configured one-way replication by removing outbound connections from replica members. One-way replication is not supported on any version of DFSR until Windows Server 2008 R2. On Windows 2008 R2 one-way replication is supported provided you configure Read-Only replicated folders. Using Read –Only DFSR members allows you to accomplish the goal of one-way replication, which is preventing unwanted changes to replicated content. If you must use one-way replication with DFSR then you must use Windows 2008 R2 and mark the members as read-only where changes to content should not occur.
Click here and here to learn about Read-Only DFSR replicas.
Another common problem that occurs is when an Admin discovers that one way replication is not supported they go about fixing it the wrong way. Simply enabling two-way replication again can have undesirable results. See the blog post below on how to recover from one-way replication.
Click here to learn about fixing one-way replication.

• Hub Server – Single Point of Failure or Overworked Hub Servers

I have seen many deployments with just one hub server. When that hub server fails the entire deployment is at risk. If you’re using Windows Server 2003 or 2008 you should have at least 2 hub servers so that if one fails the other can handle the load while the other is repaired with little to no impact to the end users. Starting with Windows Server 2008 R2 you can deploy DFSR on a Windows Failover Cluster which gives you high availability with half of the storage requirement.
Other times admins will have too many branch office servers replicating with a single hub server. This can lead to delays in replication. Knowing how many branch office servers a single hub server can service is a matter of monitoring your backlogs. There is no magic formula as each environment is unique and there are many variables.
Read the “Topology Tuning” section here for ideas on deploying hub servers.
Click here to learn how to setup DFSR a Windows Server 2008 Fail-Over Cluster.

• Too many Replicated Folders in a single Jet Database

DFSR maintain one Jet database per volume. As a result placing all of your RFs on the same volume puts them all in the same Jet Database. If that Jet database has a problem that requires repair or recovery of the database all of the RF’s on that drive are affected. It is better to spread the RFs out using as many drives as possible to provide maximum uptime for the data.

• Bargain Basement iSCSI deployments

I have seen more than one DFSR iSCSI deployment where the cheapest hardware available was used. Usually if you are using DFSR it is for some mission critical purpose such as data redundancy, backup consolidation, pushing out applications and OS upgrades on a schedule. Depending on low-end hardware with little to no vendor support is not a good plan. If the data is important to your business then the hardware that runs the OS and replication engine is important to your business.

• Did not maintain the DFSR service at the current patch level

DFSR is actively maintained by Microsoft and has updates released for it as needed. You should update DFSR when a new release is available during your normal patch cycle. Make sure your servers are up to date per the KB articles listed below.
Windows 2003 R2 DFSR Hotfixes
Windows 2008 and Windows 2008 R2 DFSR Hotfixes
You will notice that updates are listed for NTFS.SYS and other files besides DFSR.EXE/DFSRS.EXE. For replication always make sure DFSR and NTFS are at least at the highest version listed. The other patches listed mostly deal with UI issues that you will at minimum want installed on the systems you perform DFSR configuration tasks on.
Proactively patching the DFSR servers is advisable even if everything is running normally as it will prevent you from getting effected by a known issue.

• Did not maintain NIC Drivers

DFSR will only work as well as the network you provide for it. Running drivers that are 5 years old is not smart. Yes, I have talked with more than a few customers with NIC drivers that old who’s DFSR replication issue was resolved by updating the NIC driver.

• Did not monitor DFSR

Despite the fact that the data DFSR is moving around is usually mission critical many Admins have no idea what DFSR is doing until they discover a problem. Savvy admins have created their own backlog scripts to monitor their servers but a lot of customers just “hoped for the best”. The DFSR Management Pack has been out for almost a year now (and other versions for much longer). Deploy it and use it so you can detect problems and respond before they become a nightmare. If you can’t use the DFSR Ops Management pack at a minimum write a script to track your backlogs on a daily basis so that you know that DFSR is replicating files or not.
Click here for information on the Ops Manager DFSR Management Pack.

Updated Jan 19, 2011:

• Making changes to disk storage without first backing up the data
  If you must replace or add hard drive space to your DFSR server it is critical that you have a current backup of the data in case something goes wrong. Any number if things can go wrong the most common being conflict event s created due to accidental changes to a parent folder or unintentional deletion of a parent folder that is replicated to all partners. You must backup your data before starting the changes and maintain the backup until the project is completed.
   
• Stopping the DFSR service to temporarily prevent replication
  Sometimes there is a need to temporarily stop replication. The proper way to accomplish this is to set the schedule to no replication for the Replication Group in question. The DFSR service must be running to be able to read updates to the USN Journal. Do not stop the DFSR service for long periods of time (days, weeks) as doing so may cause a journal wrap to occur (if many files are modified, added, or deleted in the meantime). DFSR will recover from the journal wrap but in large deployments this will take a long time and replication will not occur or will happen very slowly during the journal wrap recovery. You may also see very high backlogs until the journal wrap recovery completes.

Windows Server 2008 Repair Steps for No Boot Issues

Startup Repair Process

Startup Repair will try to repair computers that are unbootable because of the following reasons:

• Registry corruption
• Missing or damaged system and driver files
• Disk metadata corruption (MBR, partition table, and boot sector)
• File system metadata corruption
• Installation of problematic or incompatible drivers
• Installation of incompatible Windows service packs and patches
• Corrupt boot configuration data
• Bad memory and hard disk hardware (detection only)

 http://technet.microsoft.com/en-us/library/cc722188(WS.10).aspx
How Windows RE Works
 Log file location: Startup Repair Log:
After Startup Repair has run, a text log with diagnostic information and repair result is generated within the recovery console. This log file is located at %WINDIR%\System32\LogFiles\Srt\SrtTrail.txt

•  We can execute startrep.exe tool in recovery console to address corrupt registry issues if any in Windows Server 2008 R2

 If the Windows registry is slightly or moderately corrupted, you may be able to restart the computer in Safe mode and use System Restore to restore the registry of the computer to the last known good configuration. However, if the Windows registry is severely corrupted, all types of logon will be prevented. Attempting to log on to Windows causes the system to fail and then to restart. In this situation, you will need to boot the system into the Recovery Console instead of into Windows. Once in the Recovery Console, you can use the Startup Repair tool. Startup Repair automates common diagnostic and repair tasks of unbootable Windows installations.
a)       Boot from your Windows Vista or Windows Server 2008 DVD
b)       On the first screen of Setup choose Next
c)       In the lower left of the screen choose "repair your computer"
d)       On the System Recovery Options screen choose your installation of Windows and then click next
e)       Click "Command prompt"
f)        Go to X:\sources\recovery> startrep.exe
g)       This will take a while but will address any registry related issues.
 Ref: http://technet.microsoft.com/en-us/library/cc734097(WS.10).aspx
Event ID 4005 — Windows Logon Availability

• Sfc Scannow command address file based corruptions if any.

a)       Boot from your Windows Vista or Windows Server 2008 DVD
b)       On the first screen of Setup choose Next
c)       In the lower left of the screen choose "repair your computer"
d)       On the System Recovery Options screen choose your installation of Windows and then click next
e)       Click "Command prompt"
f)        Type in the following command: SFC.EXE /scannow /offbootdir=c:\  /offwindir=c:\windows
g)       When complete type in exit to see if Windows starts up now.
 Ref: http://blogs.technet.com/b/askcore/archive/2007/12/18/using-system-file-checker-sfc-to-fix-issues.aspx
Using System File Checker (SFC) To Fix Issues

• Chkdsk to address disk and filesystem based issues.

Boot the machine in recovery console mode and run chkdsk on C: drive [Local Fixed Disk]
chkdsk C: /f and then chkdsk c: /r 
/f - Fixes errors on the disk. The disk must be locked. If chkdsk cannot lock the drive, a message appears that asks you if you want to check the drive the next time you restart the computer.
/r - Locates bad sectors and recovers readable information. The disk must be locked. /r includes the functionality of /f, with the additional analysis of physical disk errors.

 http://technet.microsoft.com/en-us/library/cc730714(WS.10).aspx
Chkdsk 

Windows Server: How to Repair the Boot Files in Windows Server 2008 or 2008 R2 if the Server Won't Boot

There are a number of possible causes for the failure of a server to boot into Windows. This article deals with a problem in the boot files and demonstrates how to repair them.

---

When booting to the Windows Recovery Environment (WinRE), the drive letters are assigned on a first-come, first-serve basis. For example, the C: drive in Windows will often have a different letter in WinRE. The DiskPart utility can be used to keep track of the drives and what is stored on them.

Note: If there is no System Reserved partition. It is okay to select the drive containing the Windows folder.

• First Partition: 100 MB System Reserved (No drive letter)
• Second Partition: 60 GB (C:) OS
• Third Partition: 1.5 TB (D:) Data
• DVD Drive: E:

Figure 1: Illustration of Drive lettering in Windows and WinRE (English only)

Note: If there is no System Reserved partition. It is okay to select the drive containing the Windows folder .

Restoring Boot Files

1. Boot to the Windows Server DVD.
2. Open the command prompt.
   1. Server 2008 R2:
      1. If no driver is needed, press Shift-F10 to open the command prompt.
      2. Continue with step 3.
   2. Server 2008 (or 2008 R2 if a driver is required)
      1. Click Next at the first screen.
      2. Click Repair your computer.
      3. If no driver is needed, click Next and proceed to step vii below.
      4. If a driver is needed, click Load Drivers.
      5. Insert the media containing the needed driver.
         Note: The media can be a CD, DVD, or USB storage device
      6. Navigate to the folder containing the driver, select it, and click Open.
      7. Click Command Prompt.
3. The command prompt appears.
4. Type DiskPart at the command prompt.
   
   Figure 2: DiskPart result (english only)
   
5. Type List vol at the DiskPart prompt.
6. Write down the drive letter of the DVD drive. In this example, it is F.
7. Write down the drive letter of the system reserved drive. In this example, it is C.
8. Type Select vol 1 (assuming volume 1 is the System Reserved volume, as it is here).
9. Type active. This sets the selected volume as active.
10. Type exit to return to the command line.
11. Type Copy f:\BootMgr c:\ at the command prompt. One of two things will happen:
    1. If the file Bootmgr already exists on C:, type N to avoid overwriting it.
    2. If the file Bootmgr doesn't already exist on C:, it will automatically be copied.
12. Type Bootrec /Fixmbr at the command prompt.
13. Type Bootrec /Fixboot at the command prompt.
14. Type Bootrec /rebuildBCD at the command prompt.
    1. If no OS is found, the following appears:
       Figure 3: Result when no OS is found (English only)
       
       This means that one of the following is true:
       1. The boot configuration database (BCD) already exists.
       2. The OS is not there.
       3. The OS is damaged beyond the ability of BootRec to recognize it.
    2. If BootRec /RebuildBCD succeeds, it will list any installations of Windows that it found. Press Y to accept and add them to the BCD.
15. The server is now configured to boot from the proper partition. Close the command prompt and reboot the system into normal mode.