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