HostBits's questions

BACKGROUND

In Exchange 2010, if you make an end user a distribution list owner they are capable of managing that list via OWA. However, the default MyDistributionGroups management role that gets assigned gives too many rights. The user would be allowed to not only manage their group but create and delete other distribution groups. That role provisions the user to be capable of running Set-DistributionGroup; Set-Group; Set-DynamicDistributionGroup; New-DistributionGroup among other commands to manage members.

There are plenty of articles circling around on how to create a new default management role that does not include the New-DistributionGroup and Remove-DistributionGroup commands.

However, this still allows the group owner to modify settings like the DisplayName and Alias. This could lead to a user creating a new email address for the distribution list and causing inadvertent issues.

In testing, I have created a management role that is based off the original MyDistributionGroups role, but does not include the commands New-DistributionGroup, Remove-DistributionGroup, and Set-Group. This allows the group owner to still manage the group, not delete or create new groups, and not change the Active Directory side settings such as the DisplayName and add or remove additional owners.

Unfortunately, it still allows them to change the Alias.

QUESTION

Does anyone know of a way to restrict group owners in Exchange 2010 so that they can manage members but not change properties like the Alias?

With the known Java threat on the loose, I've pushed a GPO to disable Java within IE. However, I'd like to disable Java across all browsers. Java provides documentation on how to do this via their new control panel: How do I disable Java in my web browser?

I'd like to push out this setting via Group Policy. I imagine this should be able to be done by identifying the registry setting that is modified by the Java Control Panel.

Has anyone identified the registry settings needed to disable Java across all browsers?

I tried looking through old questions, but couldn't find one that hit this exact question.

In VmWare's documentation on Snapshots, they mention utilizing them for a "process tree" setup. This would allow spawning multiple VMs from a base .vmdk disk. The idea is that you create a base disk and then snapshot it. This creates a "differencing" disk that is used for any changes made to the VM. I've tested this by using the following steps:

1. Create a base VM with a new .vmdk file, and configure it as needed
2. Shut down the VM
3. Create a new VM and choose to use the existing .vmdk disk.
4. Before Powering on the new VM, take a snapshot of the new VM.
   • This will create a differencing disk in the folder with the new VM
   • The new VM will write any deviations from the base, to this new .vmdk file.
5. Power on the VM
6. Repeat Steps 4-5 for additional VMs

My thought is that this could save on the amount of disk space needed to run multiple VMs on shared storage (iSCSI SAN).

The Question:

I wanted to see if anyone has run this setup and what type of performance implications can be expected (additional disk I/O, memory, etc) or any other snafus to be aware of? Are there any situations where this would cause more issues than its worth?

I've run into a strange one. Today I noticed that clients weren't registering their A records in DNS.

Our setup:

• AD integrated zone - dynamic secure updates enabled on the domain zone.
• Windows XP/ 7 clients
• DNS specific search suffixes are pushed out to PCs
  • Primary DNS suffix is listed first
• All clients are members of domain
• Clients are receiving DNS Servers via DHCP
• Clients are receiving DNS domain name via DHCP

Scavenging settings have all been ruled out as the cause of the problem.

Proper functionality would be the clients use their primary DNS suffix to register their A record with the DNS server. However, this is not happening. The only way I have been able to get the clients to register correctly is to enable the "Register DNS records with connection-specific DNS Suffix" setting in TCP/IP settings.

I can push that setting out via GPO to get the clients to register, but this seems like a band-aide.

We have other sites/ subnets that have no issues dynamically updating their dns records. These sites/ subnets have DCs that replicate to the DNS servers that are not receiving the dynamic updates from our site.

The only difference I can find is that the sites that operate correctly do not have the DNS domain name set via Group Policy.

I plan to test tomorrow by creating a new subnet that does not push out the DNS Domain Name setting. I will then see if a PC on that subnet can register it's name without having to enable the connection-specific setting.

Until then, has anyone run into anything like this or have any suggestions?

I'm having an issue where every time I add users to the Enterprise Admin group in AD they are shortly thereafter removed. I have Domain Admin rights. I'm wondering if this has anything to do with the AdminSDholder. From what I understand though, that should only affect the security ACL on the actual enterprise admin group object, not the group membership.

I keep having to re-add myself and the other Domain Admins to the group in order to manage our child domain.