Month: February 2014

Symantec Exec 2014 Beta Signups have begun – support for Windows Server 2012 R2

Symantec does not yet support BackupExec Server running on Windows Server 2012. There are a lot of frustrated customers because of this issue. A lot of admins are downgrading to Server 2008 R2 for just this reason. Backup Exec 2014 is slated for late Q2 early Q3 of 2014. Currently BE2012 SP2 running on Server 2008 R2 does have a 2012 client/agent and supports backing up 2012 clients only, but a Backup Exec 2014 beta (aka Backup Exec 2012 R2) signup has started today.

Symantec WS2012 support:
http://www.symantec.com/business/support/index?page=content&id=TECH196108

Symantec WS2012 support news:
http://www.symantec.com/connect/blogs/backup-exec-2012-r2-update-news-about-windows-server-2012-r2-support-and-target-ga

Blog post released yesterday says BE2014 Beta signups have started:
https://www-secure.symantec.com/connect/blogs/backup-exec-beta-program-important-update

Here is the Beta signup info:

Symantec Backup Exec™ 2014 Beta

Updated – February 20, 2014
We are happy to announce the next beta program for Backup Exec is open for registrations. We are seeking existing Backup Exec customers and Backup Exec prospects who are interested in testing, validating and actively providing feedback on Backup Exec within their labs and/or production environments.

 This new version of Backup Exec delivers one of the most powerful and reliable backup and recovery solutions available today. You can be among the first to see all of Backup Exec’s new features, and your valuable feedback can help shape the future of Backup Exec.

 What’s new in this new release?

Job Monitor is back!
Monitor the status of all of your jobs from one convenient panel
Back up multiple servers in a single job
Customize selections for multiple servers all at once
Configure the order of backup sources
GRT support for Exchange 2013 CU3 & SharePoint 2013
Support for Enterprise Vault 10.0.3 and 10.0.4
Support for Domino 9
New platform support
Windows Server 2012 (agent and Backup Exec server)
Windows Server 2012 R2 (agent and Backup Exec server)
VMware vSphere 5.5
Hyper-V 2012 R2
Red Hat Enterprise Linux 5.9
Red Hat Enterprise Linux 6.3
Red Hat Enterprise Linux 6.4
SUSE Linux Enterprise Server 11 SP2
Simplified upgrade experience
Scheduler enhancements
And much more!
 If you would like to participate in this Beta program, please click on “Join this Beta Program” below.

We look forward to your participation in the Backup Exec Beta.

Kind regards,

Backup Exec @ Symantec

Forward-looking Statements: Any forward-looking indication of plans for products is preliminary and all future release dates are tentative and are subject to change. Any future release of the product or planned modifications to product capability, functionality, or feature are subject to ongoing evaluation by Symantec, and may or may not be implemented and should not be considered firm commitments by Symantec and should not be relied upon in making purchasing decisions.

Requirements
Willing to submit incident reports as problems are discovered in your testing.
Willing to complete a daily journal of your beta activities (some days it may simply be one sentence).
Ability to install the Beta release into a test (non-production) and/or production environment.

Server 2012 R2 SMB (SMB2) Shares inaccessable from 2000, XP SP3, Mac client computers – Solved

Recently a lot of users complained that they could not access or mount or connect to public shares hosted by a newer Server 2012 R2 virtual machine running on Xen. The users all had a common trait that they were trying to access the shares with SMB1 from XP, and OS X on Apple/Mac computers. Windows 7 and other Server 2012 computers could access the shares without any errors. After a lot of testing, the resolution turned out to be a registry change which turned off SMB2. During testing we did the following:

  1. I created test shares on the problem server on both the c and e drives, and still was not able to connect to them with OS X 10.9.1 or XP. Whether trying to mount the shares by UNC or DNS, or IP Address, or mapped drives, I could not mount or view the shares. I modified these new shared directories permissions to see if authentication, security, or permissions were the problem, but no difference. The error message on the Macs was: “There was a problem connecting to the server “servername”. The share does not exist.” and on XP was: “The specified network name is no longer available”.
  2. I created a new share on a separate Server 2012 R2 server. My mac was able to mount this share created on it. This anomaly is what is still vexing because it’s an identical share on an identical operating system, but still the public shares had to be fixed. I looked at differences between the two server’s registries and could not find any discrepancies in the hive located at HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesLanmanServer. It would be nice for such an occasion to have an easy-to-use tool like linux’ diff, sdiff, or colordiff to compare registries side-by-side, but I digress.
  3. After finding the post by Nicolas Moreno here: http://social.technet.microsoft.com/Forums/windowsserver/en-US/bca317cd-87aa-4fd7-b12a-6715e6dddfe5/cant-access-unc-share-on-windows-server-2012-r2?forum=winserver8gen I checked the good working server and found that it’s server service is using Srv2 (smb2), but it is able to provide shares. Again, the server that can’t share with older clients also was using Srv2 (SMB2), but the symptoms were a lot like the post’s description.
  4. First, I took a snapshot of the virtual machine, I backed up the Registry Hive/Key with an export, and then made the registry change:
    HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesLanmanServerDependOnServiceFrom: SamSS Srv2To: SamSS SrvScreen Shot 2014-02-20 at 10.32.29 AM
  5. After making the change and rebooting the server, all of the clients (2000, 2003, XP, Mac OSX 10.8 Mountain Lion, Snow Leopard, Mavericks) could access the shares again.

An associate had made changes to this server prior to the incident cropping up so it’s hard to be sure just when and what caused the SMB2 windows shares to block access, but for now everyone can access the public drives. Please leave a note if this resolution helped or if you found a way to get broken SMB2 shares working again without changing the registry.

 ic_launcher

Creating and Deploying Windows7 with WDS 2012

Below is a rough procedure for using Windows Deployment Services 2012 to create and deploy images in an Active Directory Domain environment. This procedure does not cover the installation of the WDS role in 2012, as that part is fairly straightforward.

– Prerequisites include: Server 2012, Deployment Toolbench, WAIK, and WDS Role installed. After the installation, RDP into your server.

– First step is to perform a clean install from the Windows 7 Enterprise 64 .iso dvd onto a PC model which will be cloned, for example Optiplex 745

– In this case we are using Volume licensing – licensing keys are not important, they are handled by a Volume Licensing Server, you won’t have to choose licensing while deploying images

– Open WDS

– Add boot image boot.wim stored on Win7 Enterprise CD

– Name the image (win7x64)

– Right-Click – Create capture image

– Store locally – name ‘win76capture’ – next – extract image

– In some instances you will need to add drivers. Add drivers – Add driver packages – you will need at a minimum network drivers – go to manufacturers support, get .exe drivers, use 7zip to extract contents into folder and browse to that folder to add them.

– go to remote machine – power on and hit F12 for boot options – network boot/PXE boot *note: some pc’s will not have boot to NIC enabled. Do so in BIOS of system (NIC Enabled with PXE) and set boot order: 1. CD 2. HDD 3. NIC

– Now it’s time to make the PC image. For uncloned models run a base install from Windows 7 CD. After the installation process runs it will restart several times.

– Before entering any settings, and at the point during the install where it ask for the user name/PC name, hit CTRL+SHIFT+F3 to go into Audit Mode – this will RESTART the pc into Audit Mode.

– After restart, the PC will land you on the desktop with the Sysprep Tool open in Audit Mode.

– If you miss the prompt to hit ctrl+shift+f3 you can get into audit mode by running from elevated cmd prompt: c:windowssystem32sysprepsysprep.exe /audit /restart

– Leave the Sysprep tool open with the following settings: Enter sysOOBE, Generalize (checked), Shutdown Options: Reboot

– Leave the Sysprep tool open and do all software installs and settings for the end user. Office 2010 automated installer, create shortcuts for web tools, install standard apps for example: firefox, 7zip, putty, reader, pdfcreator, java, winscp, vlc, iTunes, quicktime – many times mapped drives and folder redirects will be created with .bat scripts but often times printers will have to be connected when setting up for the user. Make sure system is not set to sleep in power settings, turn off UAC, install flash etc. Be sure to open applications such as MS Office to register/activate software.

– Click OK on SYSprep and OOBE

– Restart – PXE boot again – do capture.wim – it will ask ‘select file to save to … Save to local disk as *model*Win7x64.wim. If the capture process does not see the partition C or D (in some instances D drive will actually be your C: drive) then you’ve done something wrong with Audit mode and sys prep. The capture will complete and land you either at the Owner/PC Name settings at which point you’ll do a Ctrl+Shift+F3 or at your desktop. Once back at the desktop, browse to your server at servernameshare and copy the capture.wim file to the server.

– Make sure to start WDS as administrator and can add new Image Group. If you don’t add a New Image Group the ‘add new image’ wizard may tell you the image is invalid. If you get “File does not contain a valid install image” / Add Image failed. In WDS install images – add new Image Group, then try re-adding the captured .wim. If it still says invalid image, re-copy the captured image from the PC back to servernameWDS, create a new image group and add image again.

– Right-click – Create multicast transmission/Any PC can connect/Allow Multiple etc. Create a new multicast transmission for your new image.
– Boot client PC to be imaged into PXE again and clone the machine with new image that you just captured from it, to test and make sure it works, network, drivers etc are all in place.

– if errors occur, go to image then ‘Add driver packages to image’

– if everything is good open WSIM – 2 answer files will be created: 1. Unattended and 2. OOBE (out of the box experience)

– Use unattended file in c:remoteinstallwds clientunattendedwdsunattendedwin764.xml

– Use petenet live documentation for unattended file creation settings if necessary here: http://www.petenetlive.com/KB/Article/0000735.htm (three parts)

– Pass 1: 2 modules — 1. AMD64_ms-win-international-core-winpe_neutral … 2. AMD64_ms-win-setup-neutral – credentials domain: sec un: ***admin pw: *****04

– Pass 4: 1 module — AMD64-ms-win-unattendedjoin-neutral: machine objectOU: OU=autoinstall,OU=Workbench,OU=Workstations,OU=***,OU=*****,DC=***,DC=root,DC=******,DC=com — join domain: ****.root.****.com

– File – Open – oobeunattendedwin7x64.xml:

– Pass 4 (Specialize) — 2 modules: 1. AMD64_ms-win-shell-setup-neutral: configure organization, owner, PST —- 2. AMD64_ms-win-unattendedjoin_neutral: ID join domain /OU, credentials: ***/******

– Pass 7 (oobesystem) — 2 modules: 1. amd64_ms-win-internationalcore_neutral: EN-US (everything) — 2. AMD64_ms-win-shell-setup_neutral – a. OOBE – true,true,work,1,true,true b.UserAccounts – administrator pw: **** – Local Accounts – LocalAccount [Name=”admin”]: AddListItem, admin,admin,Administrators,admin – Passwrd: ******

– Go to WDS Install Image win764 – right-click – properties – checkmark Allow image unattended – select c:remote installwdsclientunattendedoobeunattendedwin764.xml – ok

– Right-click on Server – Properties – Boot tab: default boot image x64: use boot capture.wim. — under Client Tab: Enable unattended installation

– Browse to c:remoteinstallwdsclientunattendedwdsunattendedwin7x64.xml / enable logging

– Boot client pc pxe – options are win7x64 or capture – select win7x64 – option which image you want to install (win7x64)

– PC should finish installing the image and restart, leaving you at the Ctrl+Alt+Del and already named and joined to the domain. The PC should have been added to the OU domain.com/Workstations/Workbench/autoinstall

– Log in as domain admin, add the end user account temporarily to the local administrators group, log in as the user and setup the user profile and add printers.

– Remove end-user from local administrators group – that’s it!