Vsphere Support for Memory Hot Add and CPU Hot Plug

Following is the chart for supporting Hot Add memory and Hot Plug vCPU.

Capture

 

 

 

By default, virtual machines don’t support Hot Add (add RAM) and Hot Plug (add vCPU). You need to enable this capability on a per-VM basis in order to use it. To do so, you must first shut down the virtual machine since you can’t modify these settings while it’s running. Then, open the virtual machine’s properties, navigate to the Options tab and choose the Memory/CPU Hotplug option in the Advanced section. At the right-hand side of the window, note that there are two section – one for memory and one for CPU. Choose the options you like and then click OK.

Image

Performing a Remote Mobile Wipe with Exchange server 2010

  • Open the Exchange Management Console (EMC)
  • Expand Microsoft Exchange On-Premises.
  • Expand Recipient Configuration.
  • Click Mailbox.
  • Right click to user and select Manage Mobile Phone .

1

In the Manage Mobile Phone Wizard, verify that device is selected that need to be wiped. If it isn’t, single-click to select it.

  • Under Action, click the radio button next to Perform a remote wipe to clear mobile phone data.
  • Click the Clear button.

2

  • Click Yes when prompted to confirm “Are you sure you want to clear the device for {device name}.”

3

The wizard will proceed to the completion screen where you should be presented with a message indicating the successful remote wipe command has been queued. Look closely and you’ll also notice the actual PowerShell cmdlet that’s executed by the GUI. Recall that Exchange 2010 is built to leverage the “power” of PowerShell; the GUI really just acts as a point and click front-end for the shell. Remote wipes are no exception, as they can be handled quite succinctly via two Exchange cmdlets: Get-ActiveSyncDevice and Clear-ActiveSyncDevice. Let’s jump right into that now.

All about Permissions:NTFS and Share

Share vs. NTFS

Share permissions are the permissions you set for a folder when you share that folder. The share permissions determine the type of access others have to the shared folder across the network. There are three types of share permissions: Full Control, Change, and Read.

NTFS permissions determine the action users can take for a folder or file both across the network and locally. Unlike share permissions, NTFS permissions offer several other permissions besides Full Control, Change, and Read that can be set for groups or individually. The most restrictive permission applies when share and NTFS permissions conflict.

As you get deeper into creating shares and applying NTFS permissions to various assets, you’ll eventually run into a problem: What happens when you combine share and NTFS permissions?

For example, suppose you’ve shared a folder on a Windows Server 2012 system and you’ve created the share as a read-only share for the Everyone group, but the NTFS permissions for the folder are Full Control for the Everyone group. When conflicts like this arise between share and NTFS permissions, the most restrictive permission set wins out. So, in this example, the share’s read-only permission would win the day and users would be unable to make changes to files and folders inside the share.

Likewise, if the share permissions granted the Everyone group Full Control, but the NTFS permissions were Read, the NTFS permissions would win because they’re the most restrictive.

Keep in mind that NTFS vs. NTFS permissions are additive. So, if user A has been granted NTFS Read rights and a group to which user A belongs has been granted NTFS Modify rights, then user A gets both Read and Modify rights. However, once share permissions enter the equation, things are a bit different.

Another point to note: Share permissions are only enforced if the contents of the shared folder are accessed over the network. If a user manages to log in directly to a server and access the folder through the file system on the local server, only the NTFS permissions will apply.

Explicit vs. Inherited Permissions

Each permission that exists can be assigned one of two ways: explicitly or by inheritance. For this reason, permissions are referred to as explicit permissions and inherited permissions.

• Explicit permissions are permissions that are set by default when the object is created, or by user action.

• Inherited permissions are permissions that are given to an object because it is a child of a parent object.

Similar to the way rights are managed for groups of users, permissions are best managed for containers of objects. Objects within the container inherit all the access permissions in that container.

For example, you might explicitly give permissions to a folder named MyFolder. All subfolders created within MyFolder automatically inherit the permissions assigned to MyFolder.

In the example above, it is possible to stop subfolders from inheriting access permissions. To do this, you must explicitly clear a setting that causes the inheritance.

Allow vs. Deny Permissions

When establishing permissions, you need to specify whether the entry should have access (Allow) or not have access (not Allow) to the resource.

After permissions have been set, the LSASS (Local Security Authority) controls access to the resource. LSASS compares the SID (Security ID) that you placed on the ACL (Access Control List) with the SID placed on the security access token that is given to the user at logon. If the SID associated with the user is on the ACL, the LSASS must determine whether the access is set to Allow or Deny. The Allow and Deny permissions inherit down through the structure.

Use the Deny permission sparingly, because of the fact that restrictive permissions override lenient permissions. It is more common to clear all the Allow check box for a group, thereby removing the group from the ACL.

This has the same result, giving no access to the resource. “Not-Allow” access in this way is easier to troubleshoot, manage and configure. It is easy to forget that you have used the Deny option.

You deny permissions (using explicit Deny) only to a specific user when it is necessary to override permissions that are otherwise allowed for the group to which this user belongs.

Permission Precedence

Because of the fact that users have can have many different rights settings and objects can have many different permission settings, it is possible that conflicting permission settings might apply to a particular object and access method.

When this occurs, the system must engage in a process of resolving the various permissions to determine which ones should govern the access.

Here are some rules for resolving permissions conflicts:

1. “Deny” permissions generally take precedence over “allow” permissions.

2. Permissions applied directly to an object (explicit permissions) take precedence over permissions inherited from a parent (for example from a group).

3. Permissions inherited from near relatives take precedence over permissions inherited from distant predecessors. So permissions inherited from the object’s parent folder take precedence over permissions inherited from the object’s “grandparent” folder, and so on.

4. Permissions from different user groups that are at the same level (in terms of being directly-set or inherited, and in terms of being “deny” or “allow”) are cumulative. So if a user is a member of two groups, one of which has an “allow” permission of “Read” and the other has an “allow” of “Write”, the user will have both read and write permission–depending on the other rules above, of course.

Although Deny permissions generally take precedence over allow permissions, this is not always the case. An explicit “allow” permission can take precedence over an inherited “deny” permission.

The hierarchy of precedence for the permissions can be summarized as follows, with the higher precedence permissions listed at the top of the list:

• Explicit Deny

• Explicit Allow

• Inherited Deny

• Inherited Allow

How to change the SQL Express sa password from a command prompt

To change the SQL sa password from a command prompt:

Start a command prompt by typing Start – Run – cmd

Enter the following commands, pressing Enter after each line

OSQL -S Localhost\SQLExpress -E
1> EXEC sp_password NULL, ‘New password’, ‘sa’
2> GO

 

Try to connect SQL with new password

sqlcmd -U sa -P New_Password

or

sqlcmd -S Localhost\SQLExpress -U sa -P New_Password

Migrating FSMO Roles to Windows Server 2012

Once Windows server 2012 has been added to the forest as a new domain controller, on the new server after launching PowerShell command line, Wecan  use the

Move-ADDirectoryServerOperationMasterRole

command to transfer all the FSMO roles. EAch role corresponding to a number :

 

Role Name Number
PDCEmulator 0
RIDMaster 1
InfrastructureMaster 2
SchemaMaster 3
DomainNamingMaster 4

so command like

Move-ADDirectoryServerOperationMasterRole -Identity "DC2k12" -OperationMasterRole 0,1,2,3,4

Transferring Certificates from Exchange 2003/2007 to Exchange 2010

Transferring Certificates from Exchange 2003/2007
to Exchange 2010

Problem

As a rule most of my clients use self signed certificates, (even though you can buy certs cheap as chips these days). If you have paid for a certificate I can see why you would want to transfer it to the new Exchange box, though if your using self signed certificates, it’s a simpler task to create a new one. But I was asked, and what you guys ask for, I will work out how to do 🙂

Solution

Export Certificate from Exchange 2007

1. To see what certificates are being used for what. Launch “Exchange Management Shell” > Issue the following command,

Get-ExchangeCertificate

2. Take a note of the certificates thumbprint (copy it to notepad).

Note: The Letters mean
I – IMAP
P – POP
U – Unified Messaging
W – WEB (IIS)
S – SMTP

3. To export the certificate, (Note: Put in your certificate thumbprint).

Export-ExchangeCertificate
-Thumbprint 1D5B46DBA10E2669327498BFB9F56146A47256CC
-BinaryEncoded:$true -Path c:\exported.pfx
-Password:(Get-Credential).password4. Enter your domain credentials.

5. Your exported certificate is now on the root of C: and called exported.pfx

 

Export Certificate from Exchange 2003

1. Click Start > mmc {enter} > File > Add/Remove Snap-in.

2. Add > Certificates > Add > Select “Computer account” > Next.

3. Accept the default of “Local computer” > Finish > Close > OK.

4. Expand Certificates > Personal > Certificates > locate the cert you are using for OWA etc.

5. Check the expiration date if you are unsure.

6. In the certificates console right click your certificate > All Tasks > Export.

7. At the welcome page > Next > “Select Yes Export the Private Key” > Next > Next > Leave password blank > Next > Chose where to save it > Save.

8. Next > Finish > It should say that it was successful.

 

 

Import your Certificate into Exchange 2010

1. Copy your exported.pfx file to the root of the Exchange servers C: Drive.

2. Launch Exchange Management Shell > Issue the following command,

Import-ExchangeCertificate
-FileData ([Byte[]]$(Get-Content -Path c:\exported.pfx -Encoding Byte
-ReadCount 0)) -Password:(Get-Credential).passwordOr in you exported the certificate form Exchange 2003

Import-ExchangeCertificate -FileData ([Byte[]]$(Get-Content -Path c:\exported.pfx -Encoding Byte -ReadCount 0))

Exchange 2003 Certificate Import (without a password prompt).

Exchange 2007 and 2010 Certificate Import

4. Then to enable the certificate use the following command > and Press “A” to confirm.

Get-ExchangeCertificate -DomainName mail.domainc.com | Enable-ExchangeCertificate -Services IIS,SMTP

5. Now your OWA, Active-Sync etc, will be using the imported certificate.

 

References – Credits – Or External Links
Technet

MikePfeiffer.net

Thanks to Rick Faria for pointing out this info was missing from the site 🙂

Get rid of second 169.254.x.x IPv4 address on Windows Server 2008 R2

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\ there were two AdaptorGUIDs, but only one of them had any parameters.

I created the IPAutoConfigurationEnabled parameter for both these AdaptorGUIDs with a value of 0 as instructed and re-booted.

Here are the registry entries for the two AdaptorGUIDs:

Reboot and check.

Upgrading Exchange 2010 to new hardware (Exch2010 to Exch 2010)

  1. 1.   Move the mailboxes.

Creating Move Requests using the Exchange Management Console

Launch the Exchange Management Console and navigate to Recipient Configuration/Mailbox.

Select a mailbox, or hold the CTRL key to select multiple mailboxes to move as a group.

Selecting mailboxes to move in the Exchange Management Console

In the Actions pane click on New Local Move Request.  Local Move Requests are for moves within the same Exchange organization.

Start a new Local Move Request

All of the mailboxes selected for the New Local Move Request wizard will be moved to the same target mailbox database.  Click the Browse button to choose a target mailbox database.

Browse to select a target mailbox database

Select the mailbox database to move the pilot group to and then click OK.  Click Next to continue.

Choose the target mailbox database

Leave the Move Settings as the default settings and click Next to continue.  If you encounter issues with corrupt items you may need to create a new move request for those mailboxes and choose to skip corrupted messages.

Configure the settings for the mailbox move requests

Review the list of mailboxes that will be moved and then click New to create the move requests.

Review the mailboxes to be moved

Click Finish to close the wizard.

The move requests are created and will be processed by the Exchange server.  You can view the status of the move requests in the Exchange Management Console under Recipient Configuration/Move Request.

View the status of the mailbox move requests

Right-click a move request and choose Properties to see the status of that move request.

View the progress of a mailbox move request

 

  1. 2.   Move the public and system folders.

 

This is really tough task, when you want to move public folder database from one server to another server in exchanger server 2007, Exchanger Server 2010,
before starting the activity you have to create one public folder on server,

 

Stpe-1:  After creating the public folder you have to execute the command
.\MoveAllReplicas.ps1 -Server Server1 -NewServer server2
but before executing this command you have to set the directory,
Cd program files>microsoft>exchange server>v14>scripts then execute.\MoveAllReplicas.ps1 -Server Server1 -NewServer server2

after executing your public folder will move,

 

Stpe-2: verify public folder is moved or not-
run the following command 
Get-PublicFolderStatistics -Server

 

if that is showing nothing means your public folder is moved to destination server.

Stpe-3: To get a listing of all system folders on this database, run the command

Get-publicfolder \NON_IPM_SUBTREE -recurse |ft Name,Replicas

 

Stpe-4: then you have to set public folder default on that server where you have moved,
follow the following steps,

  1. In the console tree, navigate to Organization Configuration > Mailbox.
  2. In the result pane, select the mailbox database for which you want to change the default public folder database.
  3. In the action pane, under the mailbox database name, click Properties.
  4. In Properties, click the Client Settings tab.
  5. Next to the Default public folder database box, click Browse.
  6. In Select Public Folder Database, select the public folder database from the list of public folder databases, and then click OK.
  7. Click OK

Stpe-5: Remove old public folder

  1. 3.   Move the connectors.

You can change the source transport server on your send connector(s) to the new server.

For the receive connectors, yes create any additional/custom ones on the new server and direct those hosts that use them to the new server (hopefully they’ve been using a DNS alias for this so you can just update that one DNS alias. If not, consider doing that from this point forward

You’ll also need to look at any external URLs for services such as OWA, ActiveSync, and how you’ve published those to the internet

 

4.Change all CNAME records (webmail, autodiscover) to point to new server.

 

 

5. Change all SMTP devices to route to the new server.

 

 

 

 

 

 

 

6. Change OAB Generation server.

 

7. Remove the databases from the old server.

 

1>Run Get-Mailbox -Database “Database Name” –Arbitration command to find all the arbitration mailboxes

<2>If there are some arbitration mailboxes, move them to different databases and then delete the database again

Get-Mailbox -Database “Mailbox Database” –Arbitration | New-MoveRequest –TargetDatabase “New Mailbox Database”

<3>If all above don’t work, you can use ADSIEDIT tool to delete mailbox database:

1.        Open Adsiedit.msc

2.        Connect to the configuration partition.

3.        Expand Configuration-Services-Microsoft Exchange-<Organization Name>-Administrative Groups-Servers-<Messaging Server name>-Information Stores.

4.        Delete the appropriate database.

 

7.Uninstall Exchange Server.

 

8. Shut down the old server.