Tuesday, June 30, 2015

Changing Active Directory and Exchange username

         Steps (17 total)

1

Open Active Directory Users and Computers


2

Navigate to the Employees Organizational Unit (OU)


3

Right-click on the name of the employee for the name change and select rename


4

Rename the employee


5

Rename User dialog box appears

-Full Name should be correct
-First Name should be correct
-Last Name should be changed to the new Last Name
-Display Name will change in the above step
-User Logon Name should be changed to the new Last Name
-User Logon name (pre-Windows 2000) will be changed in the above step
6

Open Exchange Management Console


7

Under Recipient Configuration click on Mailbox to view all user mailboxes


8

Right click the employee name and select Properties


9

In the General Tab

-Change the Alias to match username changed in Active Directory Users and computers
-Click Apply button
10

In the E-Mail Addresses Tab

-SMTP address with the new name should be bold
-Highlight the old address, right click and select remove
11

Update the Offline Address Book, navigate to Organization Configuration and select Mailbox


12

Select the Offline Address Book Tab


13

Right click on the Default Offline Address Book select Update


14

Click Yes in the dialog box

That should do it for both AD and Exchange.
15

Log into user computer as admin

Make sure to log out of the user account before logging in as admin.
16

Rename the user folder

User folders in Windows 7\8 are located C:\Users\
-To change the user folder name, right click folder and choose "Rename" and press Enter
17

Re-Link the correct user account folder in the registry

-Press Windows Key + R combination, type put Regedt32.exe in Run dialog box and hit Enter to open the Registry Editor.
-Navigate to the following location:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList
-Under the hood of ProfileList key, you’ll find the subkeys specific to a profile.
For example, I found out myself S-1-5-21-2944774474-1080414133-2956492554-1001. You’ll have these long subkeys equal to the number of user accounts on your system. All you need to do is that make sure the expandable registry string (REG_EXPAND_SZ) named ProfileImagePath in the right pane of these keys exists and linked properly to the correct user account folder. If you find that this is not the case, just point it to correct the location.

Tuning the Performance of the Symantec Endpoint Protection Manager console

Problem

The default configuration of the Symantec Endpoint Protection Manager (SEPM) is designed to minimize the memory and disk-space footprint. However, in larger organizations which may be leveraging multiple groups and/or replicated sites, the default settings may cause the system to under-perform or may generate error messages.

Error Message

When the current maximum amount of Java heap space is insufficient, the following errors or problems may be noticed:
  1. When trying to launch the SEPM, the error "Could not create the Java virtual machine" and the Symantec Endpoint Protection Manager service (semsrv) may not start successfully.
  2. The following error(s) may be logged repeatedly in the scm-server-0.log and scm-server-1.log log files:
    1. ATTENTION: Server side cache reached high water mark.
      INFO: Server side cache reached high water mark.
      java.lang.OutOfMemoryError: Java heap space
  3. Importing an extremely large MAC address list for the LAN Enforcer MAB Authentication may result in a Profile.xml of 0KB in size.

Cause

The Symantec Endpoint Protection Manager is a Java-based application, and consequently much of its performance will be related to the size of the Java Heap. Modifying the settings that control the size of the Java Heap will improve the performance of a wide variety of the functions performed by the Symantec Endpoint Protection Manager.

Solution

Increase the the Java heap space assigned to the SEPM service and consoles.
Symantec Endpoint Protection Manager Service
Note: Please backup the Registry before making the changes mentioned below.
  1. Stop the Symantec Endpoint Protection Manager service
  2. Open the Registry Editor and navigate to: HKLM\System\CurrentControlSet\Services\semsrv\Parameters\
  3. Set the following four registry values:
    1. JVM Option Number 0=-Xms512m
    2. JVM Option Number 1=-Xmx1024m
    3. JVM Option Number 2=-XX:MinHeapFreeRatio=40
    4. JVM Option Number 3=-XX:MaxHeapFreeRatio=70
  4. Start the Symantec Endpoint Protection Manager service
     
Symantec Endpoint Protection Manager Local Java Console
Note: Before modifying the file below, please make a backup copy of the file.
  1. If open, close the Symantec Endpoint Protection Manager Local Java Console
  2. Open sesm.bat in Notepad (default location: C:\Symantec\Symantec Endpoint Protection Manager\bin\sesm.bat)
  3. Change the following values (See Technical Information below for information regarding these values.):
    1. JVM Option Number 0=-Xms512m
    2. JVM Option Number 1=-Xmx1024m
    3. JVM Option Number 2=-XX:MinHeapFreeRatio=40
    4. JVM Option Number 3=-XX:MaxHeapFreeRatio=70
  4. Click File > Save
  5. Open the Symantec Endpoint Protection Manager Local Java Console

Symantec Endpoint Protection Manager Java Remote Console
How to modify the max-heap-size value for the downloaded JNLP file:
  1. Open a web browser and navigate to: http://:9090
  2. Download the Symantec Endpoint Protection Manager Java Remote Console by clicking the link underneath Symantec Endpoint Protection Manager Console
  3. After the JNLP file has been downloaded, open it in Notepad
  4. Find the variable max-heap-size (example: max-heap-size="512m")
  5. Decrease the specified amount of memory in max-heap-size (example: max-heap-size="256")
  6. Click File > Save
  7. Close Notepad
  8. Double-click the JNLP file to run the Symantec Endpoint Protection Manager Java Remote Console. If the problem is not solved, repeate steps 3 through 7 and decrease the specified amount of memory in max-heap-size again.

Note: The additional RAM will be allocated immediately following the service restart. You may see an immediate (but temporary) rise in disk and cpu activity as the page file size is increased. The max size varies from about 1200MB to 1400MB depending on OS and the state of the machine.

Technical Information
The Heap Size for Symantec Endpoint Protection Manager is specified with two values, stored in the registry.
  • JVM Option 0 (-Xms) specifies the minimum size of the Java Heap
  • JVM Option 1 (-Xmx) specifies the maximum size of the Java Heap.

The application will automatically increase the size of the Java Heap as required until it encounters the configured maximum size.These values can be increased to better suit the available resources on the computer. Performance can be optimized by following the guidelines below:

The Java Heap minimum size must not be larger that the Java Heap maximum size.
If the working size of the Java Heap exceeds the available physical RAM, the computer will begin paging the Java Heap. This will dramatically increase Disk I/O and reduce the overall performance.

Note: Always allow for at least 256 MB to be allocated to the Operating System. For Example: On a computer with 1 GB of RAM, the maximum value for the Java Heap should not exceed 768 MB.
The value of MinHeapFreeRatio and MaxHeapFreeRatio modify garbage collection characteristics (the ratio of free space to live objects within the heap). The values specified in this document are the defaults for JVM and they provide a good mixture of performance and reliability.

Saturday, June 13, 2015

Warning "Snapshot provider error 0xe00008526. Backup Exec could not locate a VSS software or hardware snapshot provider for this job."

Problem

Backup Exec unable to locate snapshot providers installed on the computer.

Error Message

V-79-57344-34086 - AOFO: Initalization failure on: "C:". AOFO used: Microsoft VSS. Snapshot provider error 0xe0008526: Backup Exec could not locate a VSS software or hardware snapshot provider for this job. Select a valid VSS snapshot provider for the target computer.


Application Log :
Log Name: Application
Source: VSS
Event ID: 7001
Computer:
 

Description:
VssAdmin: Unable to create a shadow copy: The volume shadow copy provider is not registered in the system.
Command-line: 'C:\Windows\system32\vssadmin.exe Create Shadow /AutoRetry=15
C: Drive properties window shows error about VSS Provider:
1. Go to Windows Explorer
2. Right click on C: drive
3. Click " Shadow Copies" tab.
4. Check for this error:
Initialization Failed:
Error: 0x80042304 : The volume shadow copy provider is not registered in the system.

Cause

The snapshot provider selected for the backup job is not installed on the server being backed up.

Solution

1.  Check that snapshot providers are installed on the system being backed up.
  • Open a command prompt.
  • Type "vssadmin list providers"
  • If nothing is returned, then there is most likely an issue with VSS that will most likely need assistance from Microsoft to resolve
    • You can also verify that VSS is properly registered by checking the following registry key:
      •  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\VSS\Providers\{b5946137-7b9f-4925-af80-51abd60b20d5}
  • If writers not listed or show they are in an error state, reboot the server and run the command again
 


2.  Change the backup job to use a specific snapshot provider.
  •  Open the backup job properties.
  •  Navigate to Advance Open File.
  •  Confirm the "Use advanced open file option" is checked.
  •  Select the appropriate snapshot provider - "Microsoft Volume Shadow Copy Service" with "System" selected in the pull down menu is typically best:
  



References

DESCRIPTION:
VSS snapshot error. Microsoft Volume Shadow Copy Service (VSS) cannot communicate with the writers. Check within Windows Services Console that the Volume Shadow Copy Service is started, and check the Windows Event viewer for errors related to this service.

ID: V-79-57344-34086
SOURCE: UMI
DESCRIPTION:
Backup Exec could not locate a VSS software or hardware snapshot provider for this job

ID: 0xe00008526
SOURCE: Error Code

Legacy ID

How to Back Up and Restore NTFS and Share Permissions

One thing that has made the NTFS permissions piece of this simpler is the Icacls tool. Icacls was developed for Windows Vista as a replacement for tools such as CaclsXcacls, and Xcacls.vbs. It was also included in Service Pack 2 for Windows Server 2003 and Windows Server 2008.
Backup and Restore of Share Permissions
To backup share permissions, export the Shares registry key.
  1. Open Regedit to the following location:

    HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Shares 
  2. Right-click the Shares registry key and select Export. Give it a file name such as shareperms.reg.
When you want to restore the permissions, double-click shareperms.reg to import it back into the registry.
Use the Reg tool to backup the registry key from the command line:
reg export HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Shares shareperms.reg
If you need to restore it at some point, just run:
reg import shareperms.reg
Backup and Restore of NTFS Permissions
Use this command to backup NTFS permissions:
icacls d:\data /save ntfsperms.txt /t /c
The /T switch allows it to get subfolder permissions too. The /C switch allows it to continue even if errors are encountered (although errors will still be displayed).
Use this command to restore them:
icacls d:\ /restore ntfsperms.txt
Note that in the command to save the permissions, I specified the target folder D:\Data, but when I restored them, I specified just D:\ as the target. Icacls is a little funky like that, and here’s why.
If you open the text file with the exported permissions (ntfsperms.txt in the above example), you’ll see that Icacls uses relative paths (in bold below). Underneath the relative paths are the permissions for the folders in Security Descriptor Definition Language (SDDL) format.
data D:AI(A;ID;FA;;;BA)(A;OICIIOID;GA;;;BA)(A;ID;FA;;;SY)(A;OICIIOID;GA;;;SY)(A;OICIID;0x1200a9;;;BU)(A;ID;0x1301bf;;;AU)(A;OICIIOID;SDGXGWGR;;;AU) data\folder1 D:AI(A;ID;FA;;;BA)(A;OICIIOID;GA;;;BA)(A;ID;FA;;;SY)(A;OICIIOID;GA;;;SY)(A;OICIID;0x1200a9;;;BU)(A;ID;0x1301bf;;;AU)(A;OICIIOID;SDGXGWGR;;;AU) data\folder2 D:AI(A;ID;FA;;;BA)(A;OICIIOID;GA;;;BA)(A;ID;FA;;;SY)(A;OICIIOID;GA;;;SY)(A;OICIID;0x1200a9;;;BU)(A;ID;0x1301bf;;;AU)(A;OICIIOID;SDGXGWGR;;;AU)
Had I specified D:\Data in the command to restore the permissions, it would have failed looking for a D:\Data\Data folder:
D:\>icacls d:\data /restore perms.txt
d:\data\data: The system cannot find the file specified.
Successfully processed 0 files; Failed processing 1 files
You might think specifying D:\ as the target in the restore command may somehow mess up the permissions on other folders at that level, but as you can see from the ntfsperms.txt output file, it only has information about the Data folder and subfolders, so that is all it will change.

Monday, June 8, 2015

Restoring DFSR (Distributed File System Replication) Data with Backup Exec

Problem

Restoring Distributed File System Replication (DFSR) Data with Backup Exec

Solution


 
In Backup Exec 11d and above, Windows 2003 R2 DFSR data is protected by using  the Microsoft DFS Replication Service Writer. For configurations that use DFSR, you can protect the replicated data by running a Shadow Copy Components Distributed File System Replication backup of the replicated data on any server that is hosting the replicated data. DFSR information is backed up and restored by selecting Shadow Components - User Data - Distributed File System Replication selections.
 


Figure 1- Backup
 

Figure 2- Restore
 



By default DFSR data is restored back to the original location assuming the DFSR "Replicated Folder" was not removed from the DFS Management Console or DFSR information was not removed from Active Directory.
With the Default Restore options checked, the DFSR data will be restored back to the "replicated folder" Preexisting folder (\DfsrPrivate\Preexisting). This will prevent the data being restored from unintentionally being replicated out to other members of the DFSR replication group.

After DFSR data is restored a DFS Replication Event will inform you to move the data from the DfsrPrivate\Preexisting folder to the replicated folder if replication to other DFSR replication members is desired.


DFS Replication Events after a restore:


Event Type: Information
Event Source: DFSR
Event Category: None
Event ID: 4104
Date: 6/17/2008
Time: 9:17:44 AM
User: N/A
Computer: CORP-FS
Description:
The DFS Replication service successfully finished initial replication on the replicated folder at local path D:\corp\home\users.

Any local pre-existing content in this replicated folder that did not exist on the primary member for Users_Home has been moved to the hidden system folder DfsrPrivate\Preexisting under the replicated folder root.

Content in the DfsrPrivate\Preexisting folder will not be replicated to other members of the replication group, and will not be deleted by the DFS Replication service during any automatic clean-up. If you would like this content to be replicated to other members, please move the content into the replicated folder outside the DfsrPrivate folder.

Replicated Folder Name: Users_Home



 
If it is desired for the DFSR data to be restored back to the original "replicated folder" and not to DfsrPrivate\Preexisting folder then an authoritative DFSR restore must be performed.
 

In the restore job properties under Advanced Setting check the box "Mark this server as primary arbitrator for replication when restoring folders managed by the File Replication Service or when restoring SYSVOL in system state".

 
This authoritative restore will restore the data back to the original "replicated folder" and replicate this restored data out to other DFSR replication members.  A series of DFS Replication Events will occur on the server where the restore is being performed and DFSR replication member servers.
 

DFS Replication events (Target server):

Event Type: Information
Event Source: DFSR
Event Category: None
Event ID: 4106
Date: 6/17/2008
Time: 11:58:13 AM
User: N/A
Computer: CORP-FS
Description:
The DFS Replication service detected that an authoritative restore was performed on the replicated folder at local path D:\corp\home\users and is processing the restore. Replication has been paused until the restore completes.

Additional Information:
Replicated Folder Name: Users_Home
Replicated Folder ID: 5A11FE16-B411-47FD-B2F5-91F061112147
Replication Group Name: CorpReplicationGroup
Replication Group ID: CC316971-DD82-4D98-BD6C-92FE1BC3FB3B
Member ID: 3906ACAA-7E8F-47A0-B3AF-17C5DB5E1345

-------------------------------------------------------------------------------------------------------------------------------

Event Type: Information
Event Source: DFSR
Event Category: None
Event ID: 4108
Date: 6/17/2008
Time: 11:58:13 AM
User: N/A
Computer: CORP-FS
Description:
The DFS Replication service successfully processed an authoritative restore for the replicated folder at local path D:\corp\home\users.

Additional Information:
Replicated Folder Name: Users_Home
Replicated Folder ID: 5A11FE16-B411-47FD-B2F5-91F061112147
Replication Group Name: CorpReplicationGroup
Replication Group ID: CC316971-DD82-4D98-BD6C-92FE1BC3FB3B
Member ID: 3906ACAA-7E8F-47A0-B3AF-17C5DB5E1345

-------------------------------------------------------------------------------------------------------------------------------


 
If an authoritative restore is performed DFSR will determine if the data being restore will replicate out and overwrite existing files on DFSR replication members through a (winning/losing) conflict resolution process.
 

The losing file or file version will be moved to the DfsrPrivate\ConflictAndDeleted folder.



DFS Replication Events (Replication Members)


Event Type: Information
Event Source: DFSR
Event Category: None
Event ID: 4412
Date: 6/17/2008
Time: 12:05:04 PM
User: N/A
Computer: BRANCH-FS
Description:
The DFS Replication service detected that a file was changed on multiple servers. A conflict resolution algorithm was used to determine the winning file. The losing file was moved to the Conflict and Deleted folder.

Additional Information:
Original File Path: D:\Users_Home\DOCS
New Name in Conflict Folder: DOCS-{0C9542D1-F31D-49D8-B57E-9247A4E862DA}-v1153
Replicated Folder Root: D:\Users_Home\DOCS
File ID: {0C9542D1-F31D-49D8-B57E-9247A4E862DA}-v241
Replicated Folder Name: D:\Users_Home
Replicated Folder ID: 5A11FE16-B411-47FD-B2F5-91F061112147
Replication Group Name: CorpReplicationGroup
Replication Group ID: CC316971-DD82-4D98-BD6C-92FE1BC3FB3B
Member ID: 3D394569-C7EF-4EF5-AE45-4D9CE5F48AA0





DFSR Redirection:

In Backup Exec 11d it is NOT possible to redirect DFS backup sets to alternate replication folders, files systems, or servers.
If the DFS replicated folders were removed from Active Directory or DFS Management then an System State restore will need to be performed on the Domain Controller to restore the DFS information back into Active Directory.  See related documents.

In Backup Exec 12 and above, DFSR Redirection is possible, BUT only to a file system on a server with an active DFSR writer.  Previous DFSR backup sets from Backup Exec 11d and current backup sets from Backup Exec 12 and above can be redirected to a drive/folder and then moved to DFS "replication folders" if desired. The original DFSR structure does not have to exist to redirect restore DFSR backups sets to a file system.

How to backup the Windows Distributed File System (DFS) and File Replication Server (FRS) Data with Backup Exec

Problem

How to backup the Windows Distributed File System (DFS) and File Replication Server (FRS) Data with Backup Exec

Solution

Namespace Technologies include DFS Namespace (DFSN) for Microsoft Windows 2003 SP1 and above, and DFS for Microsoft Windows 2003. The Namespace Technologies provide a virtual file system view of grouped shared folders from distributed servers.
 
Replication Technologies include DFS Replication (DFSR) for Microsoft Windows 2003 R2 Server and above, and File Replication Service (FRS) for Microsoft Windows 2003 Server. The Replication Technologies provide scheduled replication, bandwidth throttling, compression, and conflict resolution.
 
The Microsoft DFS Feature requires protection of configuration settings and file system data for which Backup Exec uses different data protection methods.
 
  • Standalone DFS or DFSN (Distributed File System Namespace) Technology Configurations are protected by a System State Registry Backup of the server hosting the DFS Root. Domain DFS or DFSN Configurations are protected by a System State Registry Backup of the target system, and an Active Directory Backup of the Domain Controller that hosts the DFS Root. In addition, target shares on remote servers must also be protected by a System State Registry Backup.

    NOTE:  Active Directory Granular Restore Technology [ADRA] cannot be used to restore domain DFS or DFSN configurations.

  • Distributed File System Namespace (DFSN) Technology Data with configurations that do not use Microsoft Replication Technologies must be protected by performing a File System Volume Backup of the shared data on the target server.

For configurations that use Microsoft Replication Technologies, see the following:
  • To protect DFSR and FRS Configurations, run a System State Registry and Active Directory backup of the Domain Controller that hosts the replicated data. 
IMPORTANT:  Active Directory Granular Restore Technology [ADRA] cannot be used to restore DFSR or FRS configurations.
 
  • For configurations that use DFSR Data, protect the replicated data by running a Shadow Copy Components - User Data - Distributed File System Replication backup of the replicated data on any server that is hosting the replicated data.
  • For configurations that use FRS, protect the replicated data by running a File System Volume Backup of the replicated data on any server that is hosting the replicated data.
     
NOTE:  The information listed above only pertains to Windows 2003 Systems.  Windows 2000 Systems that host the DFS Root must be backed up via User-defined Selections.  For more information on this, review the following:
 
How to create a User-defined Selection in Backup Exec for Windows Servers
 
For more information on Distributed File System Replication, review the following Microsoft TechNet Article:
 
Distributed File System Replication: Frequently Asked Questions 

Friday, June 5, 2015

Upgrading Windows Server 2008 R2 without media

Windows Server 2008 R2 introduces a new command-line utility, DISM, the Deployment Image Servicing and Management tool.    One of DISM’s many useful features is the ability to use its edition-servicing commands to upgrade an R2 installation without requiring install media.  This is functionally equivalent to Windows Anytime Upgrade in a Windows 7 client install, and can be performed on both an online or offline image, and on both full Server and Server Core installations.

Upgrades using the edition servicing method are quick, and don’t require a full reinstall of the operating system.  Deployed roles and features, and other characteristics (machine name, user and admin accounts, etc) are persisted forward.     Because the target editions are staged within the image, only the updates necessary to move from edition to the next are applied.

The upgrade options are limited to edition families, and are irreversible – you can’t downgrade once you’ve gone up an edition.  Additionally, you can’t move from full Server to Server Core (or vice versa).

The supported upgrade paths are:

·         Windows Server 2008 R2 Standard -> Windows Server 2008 R2 Enterprise -> Windows Server 2008 R2 Datacenter
·         Windows Server 2008 R2 Standard Server Core -> Windows Server 2008 R2 Enterprise Server Core -> Windows Server 2008 R2 Datacenter Server Core
·         Windows Server 2008 R2 Foundation -> Windows Server 2008 R2 Standard

The tool essential for this process, DISM.exe, is included in every installation of Windows Server 2008 R2, and the general usage for online and offline use is documented on TechNet here:  http://technet.microsoft.com/en-us/library/dd744380(WS.10).aspx

One scenario that we sometimes use internally is the online upgrading of Hyper-V hosts.  If you decide that you want to move from Enterprise’s 4 VM limit to Datacenter’s support for an unlimited number of VMs, you can migrate the VMs to another host, upgrade the old host in less than thirty minutes, and then immediately migrate the VMs back once the process is complete.  There’s no need to take the whole server offline or rebuild from scratch.

The syntax for DISM is fairly straightforward.  From an elevated command prompt, you can query for the current edition, for possible target editions, and initiate the upgrade.  To upgrade, you need to provide a valid 25-character product key for the edition to which you’re upgrading.

To determine the installed edition, run:

DISM /online /Get-CurrentEdition

To check the possible target editions, run:

DISM /online /Get-TargetEditions

Finally, to initiate an upgrade, run:

DISM /online /Set-Edition: /ProductKey:XXXXX-XXXXX-XXXXX-XXXXX-XXXXX

So, for example, to upgrade to Windows Server 2008 R2 Datacenter from a downlevel edition, you would run:

DISM /online /Set-Edition:ServerDatacenter /productkey:ABCDE-ABCDE-ABCDE-ABCDE-ABCDE

After running the /Set-Edition command, DISM will prepare the operating system for the edition servicing operation, then reboot twice while it applies the changes to the operating system.  After the final reboot, you’ll be running the new edition!  

UPDATE: One important note, the server can't be a DC at the time of upgrade.  If you demote a DC using dcpromo, you can upgrade, then re-promote it (you may need to migrate FSMO roles, etc, in order to succesfully demote.)