Archive for microsoft

Using Windows 2008 R2 File Auditing

guard

What is File Auditing?

In order to track file and folder access on Windows Servers, it is necessary to enable file and folder auditing and then identify the files and folders that are to be audited. Once correctly configured, the server security logs will then contain information about attempts to access or otherwise manipulate the designated files and folders. It is important to note that file and folder auditing is only available for NTFS volumes.

In Windows Server 2008 R2 and Windows 7, all auditing capabilities have been integrated with Group Policy. This allows administrators to configure, deploy, and manage these settings in the Group Policy Management Console (GPMC) or Local Security Policy snap-in for a domain, site, or organizational unit (OU). Windows Server 2008 R2 and Windows 7 make it easier for IT professionals to track when precisely defined, significant activities take place on the network.

The nine basic audit policies under Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\Audit Policy allow you to configure security audit policy settings for broad sets of behaviors, some of which generate many more audit events than others. An administrator has to review all events that are generated, whether they are of interest or not.

Auditing1

In Windows Server 2008 R2 and Windows 7, administrators can audit more specific aspects of client behavior on the computer or network, thus making it easier to identify the behaviors that are of greatest interest. For example, in Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\Audit Policy, there is only one policy setting for logon events, Audit logon events. In Computer Configuration\Policies\Windows Settings\Security Settings\Advanced Audit Policy Configuration\System Audit Policies, you can instead choose from eight different policy settings in the Logon/Logoff category. This provides you with more detailed control of what aspects of logon and logoff you can track

Auditing2

Planning

In addition, to plan and deploy security event auditing policies, administrators need to address a number of operational and strategic questions, including:

  • Why do we need an audit policy?
  • Which activities and events are most important to our organization?
  • Which types of audit events can we omit from our auditing strategy?
  • How much administrator time and network resources do we want to devote to generating, collecting, and storing events, and analyzing the data?

Requirements

  1. Auditing has to be enabled in the system’s security policy and in the Access Control List of a resource to successfully log events
  2. Audit policy can be enabled either through group policy or the local security policy
  3. If this is a Windows Server 2008 R2 or later operating system I recommend using the Advanced Audit Policy Configuration (Computer Configuration\Windows Settings\Security Settings\Advanced Audit Policy Configuration\Audit Policies\) as opposed to the older Audit Policy (Computer Configuration\Windows Settings\Security Settings\Local Policies\Audit Policy\)
  4. Do not mix use of both Advanced Audit Policy Configuration and the older Audit Policy: If you enable audit policy through Advanced Audit Policy Configuration either through group policy or the local security policy, I recommend using the Advanced Audit Policy Configuration at every level (local policy, site, domain and OU-linked group policy)

Configuring an Advanced Audit Policy

  • Create a Group Policy Object and name it something to the effect of File Server Audit Policy
  • Edit the GPO, browse to Computer Configuration\Windows Settings\Security Settings\Advanced Audit Policy Configuration\Audit Policies
  • For more information on each setting click the following link
  • http://technet.microsoft.com/en-us/library/dd772712%28v=ws.10%29.aspx
  • Select Object Access
  • In the Sub Category, select Audit File System. Put a tick in Configuring the following audit events and select whether you want to audit for Success or Failure

Auditing3

  • If you click on Explain, this will tell you exactly what this policy does

Auditing4

  • Once file and folder access auditing has been enabled the next step is to configure which files and folders are to be audited. As with permissions, auditing settings are inherited unless otherwise specified. By default, configuring auditing on a folder will result in access to all child subfolders and files also being audited. Just as with inherited permissions, the inheritance of auditing settings can be tuned off for either all, or individual files and folders.
  • To configure auditing for a specific file or folder begin by right clicking on it in Windows Explorer and selecting Properties. In the properties dialog, select the Security tab and click on Advanced. In the Advanced Security Settings dialog select the Auditing tab. Auditing requires elevated privileges. If not already logged in as an administrator click the Continue button to elevate privileges for the current task. At this point, the Auditing dialog will display the Auditing entries list containing any users and groups for which auditing has been enabled as shown below.

Auditing5

  • You can add Active Directory Security Groups or you can put the Everyone Group
  • Use the drop down list to control whether the auditing setting is to be applied to the current file or folder, or whether it should propagate down to all children files and/or sub-folders. Once configured, click on OK to dismiss current dialog and then Apply the new auditing settings in the Auditing Entries dialog.
  • From this point on, access attempts on the selected file or folder by the specified users and groups of the types specified will be recorded in the server’s security logs which may be accessed using the Events Viewer

Auditing6

Links

http://technet.microsoft.com/en-us/library/dd560628%28v=ws.10%29.aspx

Active Directory Certificate Services on Windows Server 2012

Certificate

Active Directory Certificate Services

Active Directory Certificate Services (AD CS) is an Identity and Access Control security technology that provides customizable services for creating and managing public key certificates used in software security systems that employ public key technologies.

What is a Certificate?

  • An Electronic document which contains information
  • Has an Issuer
  • Contains who the certificate is issued to
  • Contains an expiry date
  • Contains a public key which allows data to be encrypted only by someone who has the Private Key
  • Contains a digital signature which proves the certificate came from a trusted source and provides a checksum to the certificate for checking the certificate has not be altered

Features in AD CS

By using Server Manager, you can set up the following components of AD CS:

  • Certification authorities (CAs). Root and subordinate CAs are used to issue certificates to users, computers, and services, and to manage certificate validity.
  • Web enrollment. Web enrollment allows users to connect to a CA by means of a Web browser in order to request certificates and retrieve certificate revocation lists (CRLs).
  • Online Responder. The Online Responder service decodes revocation status requests for specific certificates, evaluates the status of these certificates, and sends back a signed response containing the requested certificate status information.
  • Network Device Enrollment Service. The Network Device Enrollment Service allows routers and other network devices that do not have domain accounts to obtain certificates.
  • Certificate Enrollment Web Service. The Certificate Enrollment Web Service enables users and computers to perform certificate enrollment that uses the HTTPS protocol. Together with the Certificate Enrollment Policy Web Service, this enables policy-based certificate enrollment when the client computer is not a member of a domain or when a domain member is not connected to the domain.
  • Certificate Enrollment Policy Web Service. The Certificate Enrollment Policy Web Service enables users and computers to obtain certificate enrollment policy information. Together with the Certificate Enrollment Web Service, this enables policy-based certificate enrollment when the client computer is not a member of a domain or when a domain member is not connected to the domain.

cert15

Benefits of AD CS

Organizations can use AD CS to enhance security by binding the identity of a person, device, or service to a corresponding private key. AD CS gives organizations a cost-effective, efficient, and secure way to manage the distribution and use of certificates.

Applications supported by AD CS include

  • Secure/Multipurpose Internet Mail Extensions (S/MIME)
  • Secure wireless networks
  • Virtual private network (VPN)
  • Internet Protocol security (IPsec)
  • Encrypting File System (EFS)
  • Smart card logon
  • Secure Socket Layer/Transport Layer Security (SSL/TLS)
  • Digital signatures.

Among the new features of AD CS are:

  • Improved enrollment capabilities that enable delegated enrollment agents to be assigned on a per-template basis.
  • Integrated Simple Certificate Enrollment Protocol (SCEP) enrollment services for issuing certificates to network devices such as routers.
  • Scalable, high-speed revocation status response services combining both CRLs and integrated Online Responder services

Hardware and software considerations

AD CS requires Windows Server 2008 and Active Directory Domain Services (AD DS). Although AD CS can be deployed on a single server, many deployments will involve multiple servers configured as CAs, other servers configured as Online Responders, and others serving as Web enrollment portals. CAs can be set up on servers running a variety of operating systems, including Windows Server 2008, Windows Server 2003, and Windows 2000 Server. However, not all operating systems support all features or design requirements, and creating an optimal design will require careful planning and testing before you deploy AD CS in a production environment

A limited set of server roles is available for a Server Core installation of Windows Server 2008 and for Windows Server 2008 for Itanium-based systems. AD CS cannot be installed on Server Core or Itanium-based installations of Windows Server 2008.

Managing AD CS

You can use either Server Manager or Microsoft Management Console (MMC) snap-ins to manage AD CS role services. Use the following steps to open the snap-ins:

  • To manage a CA, use the Certification Authority snap-in. To open the Certification Authority snap-in, click Start, click Run, type certsrv.msc, and click OK.
  • To manage certificates, use the Certificates snap-in. To open the Certificates snap-in, click Start, click Run, type certmgr.msc, and click OK.
  • To manage certificate templates, use the Certificate Templates snap-in. To open the Certificate Templates snap-in, click Start, click Run, type certtmpl.msc, and click OK.
  • To manage an Online Responder, use the Online Responder snap-in. To open the Online Responder snap-in, click Start, click Run, type ocsp.msc, and click OK.

Installing Certificate Services. Setting up an Enterprise CA

  • Open Server Manager
  • Click Add Roles and Features

cert1

  • Select Role based or feature based installation

cert2

  • Select Destination Server

cert3

  • Select Active Directory Certificate Services

cert4

  • Click Add Features

cert5

  • Click Next on Select Features

cert6

  • Read the Active Directory Certificate Services Page and click Next

cert7

  • On the Select Role Services, select Certification Authority and Online Responder

cert9

  • Read the Web Server Role (IIS) Page

cert10

  • Select IIS Role Services

cert11

  • Check the Confirm Installation Selections Page

cert12

  • Finish
  • On the Dashboard Page, you will see a warning triangle saying Further Configuration is needed
  • Click Configure Active Directory Services

cert13

  •  Specify the Credentials to configure Certificate Services

cert14

  • Select Role Services to Configure

cert16

  • Choose Enterprise CA

cert17

  • Specify CA type. Choose Root CA

A root CA is the CA that is at the top of a certification hierarchy. It must be trusted unconditionally by clients in your organization. All certificate chains terminate at a root CA. Whether you use enterprise or stand-alone CAs, you need to designate a root CA.

Since the root CA is the top CA in the certification hierarchy, the Subject field of the certificate that is issued by a root CA has the same value as the Issuer field of the certificate. Likewise, because the certificate chain terminates when it reaches a self-signed CA, all self-signed CAs are root CAs. The decision to designate a CA as a trusted root CA can be made at the enterprise level or locally by the individual IT administrator.

A root CA serves as the foundation upon which you base your certification authority trust model. It guarantees that the subject’s public key corresponds to the identity information shown in the subject field of the certificates it issues. Different CAs might also verify this relationship by using different standards; therefore, it is important to understand the policies and procedures of the root certification authority before choosing to trust that authority to verify public keys.

The Root CA is the most important CA in your hierarchy. If your root CA is compromised, all CAs in the hierarchy and all certificates issued from it are considered compromised. You can maximize the security of the root CA by keeping it disconnected from the network and by using subordinate CAs to issue certificates to other subordinate CAs or to end users

cert18

  • Specify the type of the Private Key
  • Create a new Private Key

cert19

  • Specify the Cryptographic Options
  • Accept the default values

cert20

  • Specify the name of the CA

cert21

  • Specify the validity Period
  • Defaults to 5 years

cert22

  • Specify the Database Location

cert23

  • Check the Confirmation

cert24

  • Check Results
  • Click on the Web Links to learn more

cert25

  • Now you can hold down the Windows Key and Q which will open the Aero view
  • Select Certificate Services which will open the below

cert26

Configure the CA

After a root or subordinate CA is installed, you must configure the Authority Information Access (AIA) and CRL distribution point (CDP) extensions before the CA issues any certificates. The AIA extension specifies where to find up-to-date certificates for the CA. The CDP extension specifies where to find up-to-date CRLs that are signed by the CA. These extensions apply to all certificates that are issued by that CA.

Configuring these extensions ensures that this information is included in each certificate that the CA issues so that it is available to all clients. This ensures that PKI clients experience the least possible number of failures due to unverified certificate chains or certificate revocations, which can result in unsuccessful VPN connections, failed smart card sign-ins, or unverified email signatures.

As a CA administrator, you can add, remove, or modify CRL distribution points and the locations for CDP and AIA certificate issuance. Modifying the URL for a CRL distribution point only affects newly issued certificates. Previously issued certificates will continue to reference the original location, which is why you should establish these locations before your CA distributes any certificates.

Consider these guidelines when you configure CDP extension URLs:

  • Avoid publishing delta CRLs on offline root CAs. Because you do not revoke many certificates on an offline root CA, a delta CRL is probably not needed.
  • Adjust the default LDAP:/// and HTTP:// URL locations on the Extensions tab of the certification authority’s Properties Extension tab according to your needs.
  • Publish a CRL on an HTTP Internet or extranet location so that users and applications outside the organization can perform certificate validation. You can publish the LDAP and HTTP URLs for CDP locations to enable clients to retrieve CRL data with HTTP and LDAP.
  • Remember that Windows clients always retrieve the list of URLs in sequential order until a valid CRL is retrieved.
  • Use HTTP CDP locations to provide accessible CRL locations for clients running non-Windows operating systems.

cert27

Active Directory Certificate Services Best Practices

http://microsoftguru.com.au/2012/11/10/active-directory-certificate-services-best-practices/

Microsoft lab for building a two-tier certification authority PKI hierarchy

http://technet.microsoft.com/library/hh831348.aspx

Accessing the help files

  • Click Start > Run > Type hh certmgr.chm

DFS Troubleshooting on Windows Server 2008 R2

helpicon

DFS Troubleshooting

The DFS Management MMC is the tool that can manage most common administration activities related to DFS-Namespaces. This will show up under “Administrative Tools” after you add the DFS role service in Server Manager. You can also add just the MMC for remote management of a DFS namespace server. You can find this in Server Manager, under Add Feature, Remote Server Administration Tools (RSAT), Role Administration Tools, File Services Tools.

Another option to manage DFS is to use DFSUTIL.EXE, which is a command line tool. There are many options and you can perform almost any DFS-related activity, from creating a namespace to adding links to exporting the entire configuration to troubleshooting. This can be very handy for automating tasks by writing scripts or batch files. DFSUTIL.EXE is an in-box tool in Windows Server 2008.

What can go wrong?

  • Access to the DFS namespace
  • Finding shared folders
  • Access to DFS links and shared folders
  • Security-related issues
  • Replication latency
  • Failure to connect to a domain controller to obtain a DFSN namespace referral
  • Failure to connect to a DFS server
  • Failure of the DFS server to provide a folder referral

Methods of Troubleshooting

I have a very basic lab set up with DFS running on 2 servers. I will be using this to demonstrate the troubleshooting methods

My DFS Namespace is \\dacmt.local\shared

Troubleshooting Commands

  • dfsutil.exe /spcinfo

Determine whether the client was able to connect to a domain controller for domain information by using the DFSUtil.exe /spcinfo command. The output of this command describes the trusted domains and their domain controllers that are discovered by the client through DFSN referral queries. This is known as the “Domain Cache”

dfs1

  • start \\10.1.1.160 (where 10.1.1.160 is your DC)

This should pop up with an Explorer box listing the shares hosted by your Domain Controller

dfs2

  •  netview \\10.1.1.160 (where 10.1.1.160 is your DC)

A successful connection lists all shares that are hosted by the domain controller.

dfs3

  • net view \\10.1.1.200 (Where 10.1.1.200 is your DFS Server)

You can see this shows you your namespace and your shares held on your DFS Server

dfs7

  • dfsutil.exe /pktinfo 

If the above connection tests are successful, determine whether a valid DFSN referral is returned to the client after it accesses the namespace. You can do this by viewing the referral cache (also known as the PKT cache) by using the DFSUtil.exe /pktinfo command

If you cannot find an entry for the desired namespace, this is evidence that the domain controller did not return a referral

dfs4

  • dfsutil.exe cache domain flush
  • dfsutil.exe cache referral flush
  • dfsutil.exe cache provider flush

dfs6

  • ipconfig /flushdns and dfsutil.exe /pktflush and dfsutil.exe /spcflush

By default, DFSN stores NetBIOS names for root servers. DFSN can also be configured to use DNS names for environments without WINS servers. For more information, click the underlined link to view the article in the Microsoft Knowledge Base:

dfs8

  •  DFS and System Configuration

Even when connectivity and name resolution are functioning correctly, DFS configuration problems may cause the error to occur on a client. DFS relies on up-to-date DFS configuration data, correctly configured service settings, and Active Directory site configuration.

First, verify that the DFS service is started on all domain controllers and on DFS namespace/root servers. If the service is started in all locations, make sure that no DFS-related errors are reported in the system event logs of the servers.

dfs9

  • repadmin /showrepl * dc=dacmt,dc=local

When an administrator makes a change to the domain-based namespace, the change is made on the Primary Domain Controller (PDC) emulator master. Domain controllers and DFS root servers periodically poll PDC for configuration information. If the PDC is unavailable, or if “Root Scalability Mode” is enabled, Active Directory replication latencies and failures may prevent servers from issuing correct referrals.

dfs10

  • DFS and NTFS Permissions

If a client cannot gain access to a shared folder specified by a DFS link, check the following:

  • Use the DFS administrative tool to identify the underlying shared folder.
  • Check status to confirm that the DFS link and the shared folder (or replica set) to which it points are valid. For more information, see “Checking Shared Folder Status” earlier in this chapter.
  • The user should go to the Windows Explorer DFS property page to determine the actual shared folder that he or she is attempting to connect to.
  • The user should attempt to connect to the shared folder directly by way of the physical namespace. By using a command such as ping, net view or net use, you can establish connectivity with the target computer and shared folder.
  • If the DFS link has a replica set configured, then be aware of the latency involved in content replication. Files and folders that have been modified on one replica might not yet have replicated to other replicas.

It is also worth checking you do not have any general networking issues on the server you are connecting from and also that there are no firewall rules or Group Policies blocking File and Printer Sharing!

  • DFS Tab on DFS folders accessed through the DFS Namespace

It is recommended that one of the first things that you determine when tracking an access-related issue with DFS is the name of the underlying shared folder that the client has been referred to. In Windows 2000, there is a shell extension to Windows Explorer for precisely this purpose. When you right-click a folder that is in the DFS namespace, there is a DFS tab available in the Properties window. From the DFS tab, you can see which shared folder you are referencing for the DFS link. In addition, you can see the list of replicas that refer to the DFS link, so you can disconnect from one replica and select another. Finally, you can also refresh the referral cache for the specified DFS link. This makes the client obtain a new referral for the link from the DFS server.

dfs11

  • Replication Latency

Because the topology knowledge is stored in the domain’s Active Directory, there is some latency before any modification to the DFS namespace is replicated to all domain controllers.

From an administrator’s perspective, remember that the DFS administrative console connects directly to a domain controller. Therefore, the information that you see on one DFS administrative console might not be identical with the information about another DFS administrative console (which might be obtaining its information from a different domain controller).

From a client’s perspective, you have the additional possibility that the client itself might have cached the information before it was modified. So, even though the information about the modification might have replicated to all the domain controllers, and even if the DFS servers have obtained updates about the modification, the client might still be using an older cached copy. The ability to manually flush the cache before the referral time-out has expired, which is done from the DFS tab in the Properties window in Windows Explorer, can be useful in this situation.

  • dfsdiag /testdcs /domain:dacmt.local
  • DFSDiag /testsites /dfspath:\\dacmt.local\Shared\Folder 1 /full
  • DFSDiag /testsites /dfspath:\\dacmt.local\Shared /recurse /full
  • DFSDiag /testdfsconfig /dfsroot:\\dacmt.local\Shared
  • DFSDiag /testdfsintegrity /dfsroot:\\dacmt.local\Shared
  • DFSDiag /testreferral /dfspath:\\dacmt.local\Shared

With this you can check the configuration of the domain controllers on your DFS Server. It verifies that the DFS Namespace service is running on all the DCs and its Startup Type is set to Automatic, checks for the support of site-costed referrals for NETLOGON and SYSVOL and verifies the consistency of site association by hostname and IP address on each DC.

dfs12
and

dfs13

and

dfs14

DFSR and File Locking

DFS lacks a central feature important for a collaborative environment where inter-office file servers are mirrored and data is shared: File Locking. Without integrated file locking, using DFS to mirror file servers exposes live documents to version conflicts. For example, if a colleague in Office A can open and edit a document at the same time that a colleague in Office B is working on the same document, then DFS will only save the changes made by the person closing the file last.

There is also another version conflict potential which arises even when the two colleagues are not working on the same file at the same time. DFS Replication is a single-threaded operation, a “pull” process. The result, synchronisation tasks are able to quite easily “queue” up and create a backlog. As a result changes made at one location are not immediately replicated to the other side. It is this time delay which creates yet another opportunity for file version conflicts to occur.

http://blogs.technet.com/b/askds/archive/2009/02/20/understanding-the-lack-of-distributed-file-locking-in-dfsr.aspx

NETBIOS Considerations

In terms of NetBios, the default behavior of DFS is to use NetBIOS names for all target servers in the namespace. This allows clients that support NetBios only name resolution to locate and connect to targets in a DFS namespace. Administrators can use NetBIOS names when specifying target names and those exact paths are added to the DFS metadata. For example, an administrator can specify a target \\dacmt\Users, where dacmt is the NetBIOS name of a server whose DNS or FQDN name is dacmt.local

http://support.microsoft.com/kb/244380

Setting up a Mandatory Roaming Profile on 2008 R2

Roaming

What is a Mandatory Roaming Profile?

A mandatory user profile is a special type of pre-configured roaming user profile that administrators can use to specify settings for users. With mandatory user profiles, a user can modify his or her desktop, but the changes are not saved when the user logs off. The next time the user logs on, the mandatory user profile created by the administrator is downloaded. There are two types of mandatory profiles: normal mandatory profiles and super-mandatory profiles.

User profiles become mandatory profiles when the administrator renames the NTuser.dat file (the registry hive) on the server to NTuser.man. The .man extension causes the user profile to be a read-only profile.

User profiles become super-mandatory when the folder name of the profile path ends in .man; for example, \\server\share\mandatoryprofile.man\.

Super-mandatory user profiles are similar to normal mandatory profiles, with the exception that users who have super-mandatory profiles cannot log on when the server that stores the mandatory profile is unavailable. Users with normal mandatory profiles can log on with the locally cached copy of the mandatory profile.

Only system administrators can make changes to mandatory user profiles.

This has advantages and disadvantages

Advantages

  • Since mandatory profiles are read-only, a single mandatory profile can be used for large groups of users. Storage requirements are minimal – a single mandatory profile is kept on the file servers instead of thousands of roaming profiles.
  • Users cannot interfere with a mandatory profile. As soon as they log off and back on, everything is reset to its original created state.
  • Because a mandatory profile can be used for large groups of users, very few mandatory profiles are needed. This makes manual customization possible. Adding a link here and changing a registry value there poses no problems at all. Compare this to thousands of roaming profiles – carefully fine tuning each profile is out of the question for the huge amount of work involved.
  • Mandatory profiles must not contain user-specific data. That makes them very small. As a result, logons are fast since the amount of data that needs to be copied over the network is negligible

Disadvantages

  • Users like to customize their own work environment in some way or another. These customizations are stored in the user profile. With mandatory profiles, any changes are discarded upon logoff. This can tend to annoy users who have saved work only to find it gone on their next logon but with education this can be a business process that everyone should adhere to
  • Mandatory profiles are difficult to create. Although the process looks pretty straightforward at first, it is hard to get exactly right. Do not underestimate the amount of tuning required.

Instructions on setting up a Mandatory Roaming Profile

  1. Create a folder called Profiles on one of your servers
  2. Right click on the folder and select Properties
  3. Click Sharing > Advanced Sharing
  4. Put a tick in Share this folder

Roaming1

  • Select permissions and remove the Everyone Group and add Authenticated User with Read Permissions and Administrators with Full Control

Roaming2

  • Click OK and click Security to set the NTFS Permissions on the folder
  • System should have Full Control
  • Administrators should have Full Control
  • Authenticated Users should have Read and Execute

Roaming4

  • Inside the Profiles folder you need to create a folder which will house your Mandatory Roaming Profile Account. See below. It needs to have .v2 added on to the end of it

Roaming5

  • Create a new Profile in Active Directory. I called mine Mandatory
  • Add the security groups you need for this account

Roaming3

  •  Next you will need to log on to a server as your mandatory profile and configure the necessary customisations. For example put shortcuts on the desktop, pin applications to the Start menu and open applications and configure settings etc
  • When you have finished customising then you will need to log off
  • Next log on with a different Administrator account
  • Click Start > Right click on My Computer and select Properties. Select Advanced System Settings
  • Click Settings under User Profiles

Roaming6

  • You will then see your profiles. I have left my mandatory one highlighted for visibility.
  • Then I encountered a problem. It turns out in Windows 2008 R2 and Windows 7, Microsoft has disabled the “Copy To” button on the User Profiles screen. See link below for more information but carry on for now. You can read this later as well.
  • http://support.microsoft.com/kb/973289

Roaming7

  • I have found a way to get round this by using a piece of software called Windows Enabler. You will need to download and extract this to the server where the profile is. Should look like the below screenprint

Roaming8

  • Right click on Windows Enabler and select Run as Administrator
  • Once you have started the Windows Enabler application you will notice a new icon in the system tray.
  • Make sure you click on it once to enable the application. You will see a small message appear on the icon when you have enabled it
  • Click Start > Run and type sysdm.cpl

Roaming10

  • Navigate to the Advanced tab | User profiles | Settings
  • Click on the desired profile and you will notice that ‘Copy To‘ button is disabled
  • Click on the Copy To button and you will notice it will become enabled
  • Click Copy To and the following box will pop up

Roaming11

  • Click Browse and browse or type the location where you set up the folder share \\server\profiles\mandatory.v2
  • Click on Permitted to use > Change and select Everyone

Roaming12

  • You will get a message come up as per below screenprint

Roaming13

  • If it errors after this message then the account you are trying to use to copy the profile does not have access to the \\server\profiles\mandatory.v2 folder
  • When it has copied, have a look at the share and check you have all your user profile folders there

Roaming14

  • Next you need to look for a file called NTUSER.DAT in the profile folder
  • You may need to open Folder Options and deselect Show Hidden folders, Files and Drives and possibly Hide Protected Operating System Files

Roaming15

  • You will then see it in the Profile folder

Roaming16

  •  Leave this for now and go Start > Run > regedit and highlight HKEY_LOCAL_MACHINE

Roaming20

  • Click File > Load Hive > Select ntuser.dat

Roaming21

  • In Load Hive put in your username which is mandatory

Roaming22

  • You will see the profile as per below screenprint

Roaming23

  • Right click on the mandatory key and select Permissions

Roaming24

  • You need to add Domain Admins Full Control and replace all child object permissions with inheritable permissions from this object and replace all child object permissions
  • You need to add Authenticated Users Full Control and replace all child object permissions
  • You need to add Domain Admins Full Control and replace all child object permissions
  • See screenprint below

Roaming26

  • Now we need to unload the hive. Go to File Unload Hive

Roaming27

  • Now go back to your mandatory profile folder and we need to rename ntuser.dat to ntuser.man. When you have renamed it, it should look like the below (ntuser.man)

Roaming17

  • Next Delete the Local and LocalLow folders from the AppData folder if they exist. They are Local profile folders and uneeded
  • Next we need to configure a Group Policy to enable the mandatory profile for Remote Desktop Services
  • Open up GPMC
  • Create a new GPO and attach it to your Terminal Server/RDS OU
  • Add the RDS Servers into the scope along with Authenticated Users
  • Navigate to Computer Configuration > Policies > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Profiles > Use Mandatory Profiles on the RD Session Host Server

Roaming19

  • Navigate to Computer Configuration > Policies > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Profiles >Set Path for Remote Desktop Services Roaming User Profile > Enabled
  • Navigate to Computer Configuration > Policies > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Profiles >Set Path for Remote Desktop Services Roaming User Profile > \\servername\profiles\mandatory (Do not include the .v2 on the end of the profile folder name)

Roaming31

  • You now need to run a gpupdate /force on the Domain Controller and on the Terminal/RDS Servers to refresh Group policy
  • Now test logging on to an RDS Server and note you will be able to save a doc say into My Documents but try logging off and logging on again and you will find it has gone
  • If you go Start > Run sydm.cpl > Advanced > User Profiles > Settings > Check your user profile which you have logged on with (In my case Eskimo1) you should see that the type of profile is now mandatory

Roaming29

  • Congratulations. You have set up a Mandatory Roaming Profile 🙂

Using Windows Firewall to block Ports

firewall

What is Windows Firewall with Advanced Security in Windows?

Windows Firewall with Advanced Security in Windows® 7, Windows Vista®, Windows Server® 2008 R2, and Windows Server® 2008 is a stateful, host-based firewall that filters incoming and outgoing connections based on its configuration. While typical end-user configuration of Windows Firewall still takes place through the Windows Firewall Control Panel, advanced configuration now takes place in a Microsoft Management Control (MMC) snap-in named Windows Firewall with Advanced Security. The inclusion of this snap-in not only provides an interface for configuring Windows Firewall locally, but also for configuring Windows Firewall on remote computers and by using Group Policy. Firewall settings are now integrated with Internet Protocol security (IPsec) settings, allowing for some synergy: Windows Firewall can allow or block traffic based on some IPsec negotiation outcomes.

Windows Firewall with Advanced Security supports separate profiles (sets of firewall and connection security rules) for when computers are members of a domain, or connected to a private or public network. It also supports the creation of rules for enforcing server and domain isolation policies. Windows Firewall with Advanced Security supports more detailed rules than previous versions of Windows Firewall, including filtering based on users and groups in Active Directory, source and destination Internet Protocol (IP) addresses, IP port number, ICMP settings, IPsec settings, specific types of interfaces, services, and more.

Windows Firewall with Advanced Security can be part of your defense in depth security policy. Defense in depth is the implementation of a security policy that uses multiple methods to protect computers and all components of the network from malicious attacks.

Protection must extend from the network perimeter to:

  • Internal networks
  • Computers in the internal network
  • Applications running on both servers and clients
  • Data stored on both servers and clients

Windows Firewall with Advanced Security provides a number of ways to implement settings on both local and remote computers. You can configure Windows Firewall with Advanced Security in the following ways:

  • Configure a local or remote computer by using either the Windows Firewall with Advanced Security snap-in or the Netsh advfirewall command.
  • Configure Windows Firewall with Advanced Security Group Policy settings by using the Group Policy Management Console (GPMC) or by using the Netsh advfirewall command.

Rules

Firewall rules from different sources are first merged together. Rules can be stored on the local computer, or in a variety of Group Policy objects (GPOs).

Windows Firewall with Advanced Security uses a specific order in which firewall rule evaluation takes place.

This order is as follows:

FirewallRules

Example Firewall Tasks

One task we were asked to was to block our TEST Terminal Servers from being able to connect to DFS Shares on a DEV DFS Server. Below is a list of points to bear in mind.

  • It is best to control Server Firewall Rules by Group Policy
  • The GPO needs to apply to a Computer OU containing the DEV Server
  • The DEV Server can be put in the scope of the GPO
  • We could have an option to turn the Firewall on and then block servers
  • We could have an option to turn the Firewall off and then allow servers
  • We could use inbound rules blocking the DFS Ports – TCP Port 445 (SMB) TCP Port 135 (RPC) TCP Port 139 (NetBIOS Session Service) UDP Port 137 (NetBIOS Name Resolution) UDP Port 138 (NetBIOS Datagram Service)
  • If you set up Inbound Rules, you then need to set the scope which includes setting the Local Server IP Address (The DEV DFS Server) and the Remote Servers IP Addresses (The servers you want to block)

Useful Link for showing what ports applications use

http://technet.microsoft.com/en-us/library/cc875824.aspx

Example 1 (Turn Firewall On and Allow connections but block TEST Servers)

  • Open Group Policy Management
  • Right click on DEV DFS Server OU and select Create a GPO in this domain , and Link it here
  • Put in a name
  • Right click on new GPO and select Edit
  • Navigate to Computer Configuration > Polices > Administrative Templates > Network > Network Connections > Windows Firewall > Domain Profile and Enable Windows Firewall: Protect all network connections

firewallblock12

  • Navigate to Computer Configuration > Polices > Windows Settings > Security Settings > Windows Firewall with Advanced Security
  • Click on Windows Firewall Properties (See Circled below)

firewallblock

  • Go through Domain Profile, Private Profile and Public Profile and set the following options for each one

firewallblock2

firewallblock3

firewallblock4

  • Navigate to Computer Configuration > Polices > Windows Settings > Security Settings > Windows Firewall with Advanced Security > Inbound Rules
  • Right clicked on Inbound rule > Selected New inbound rule > Select Custom

firewallblock5

  • Choose All Programs

firewallblock6

  • Choose Any for Protocol Type

firewallblock7

  • In Scope, leave the Local IP Addresses as Any IP Address and then for the Remote IP Addresses, put in the IP Addresses of the servers you want to block

firewallblock8

  • Choose Block as your Action

firewallblock9

  • Apply the rule to all Profiles

firewallblock10

  • Put in a Rule Name and Description

firewallblock11

  • Click Finish
  • Test accessing a DFS Share from a blocked server. It should be blocked

firewall20

 The second way of doing this

The second way of doing this is a kind of reverse way of doing this by turning the Windows Firewall on through Group Policy which by default should look like the below on a DFS Server when GPO is applied so you are blocking incoming connections but then you modify the Group Policy to only allow certain networks to use File and Printer Sharing.

Capture

  • Next log into Group Policy Management Console
  • Create a new GPO and attach it to your DFS Servers
  • Put the DFS Servers in the scope of the GPO
  • Now adjust the following settings
  • Computer Configuration > Policies > Windows Settings > Security Settings > Windows Firewall with Advanced Security > Domain Profile > Firewall State (Turn On)
  • Computer Configuration > Policies > Windows Settings > Security Settings > Windows Firewall with Advanced Security > Domain Profile >Inbound Connections (Block Default)
  • Computer Configuration > Policies > Windows Settings > Security Settings > Windows Firewall with Advanced Security > Domain Profile > Outbound Connections (Allow Default)
  • Computer Configuration > Policies > Windows Settings > Security Settings > Windows Firewall with Advanced Security > Private Profile > Firewall State (Turn On)
  • Computer Configuration > Policies > Windows Settings > Security Settings > Windows Firewall with Advanced Security > Private Profile >Inbound Connections (Block Default)
  • Computer Configuration > Policies > Windows Settings > Security Settings > Windows Firewall with Advanced Security > Private Profile > Outbound Connections (Allow Default)
  • Computer Configuration > Policies > Windows Settings > Security Settings > Windows Firewall with Advanced Security > Public Profile > Firewall State (Turn On)
  • Computer Configuration > Policies > Windows Settings > Security Settings > Windows Firewall with Advanced Security > Public Profile >Inbound Connections (Block Default)
  • Computer Configuration > Policies > Windows Settings > Security Settings > Windows Firewall with Advanced Security > Public Profile > Outbound Connections (Allow Default)
  • Computer Configuration > Administrative Templates > Network > Network Connections > Windows Firewall > Domain Profile > Windows Firewall: Protect all network connections (Enable)
  • Computer Configuration > Administrative Templates > Network > Network Connections > Windows Firewall > Domain Profile > Windows Firewall: Allow inbound file and printer sharing (You will need to enable this and then put in the network which is allowed to access this)

fileandprint

  • Computer Configuration > Administrative Templates > Network > Network Connections > Windows Firewall > Domain Profile > Windows Firewall: Allow inbound Remote Desktop Connections
  • And then test this from a network you want to block from your DFS Servers etc
  • Voila 🙂

DHCP Failover in Windows Server 2012

dhcp

DHCP Failover Overview

DHCP failover in Windows Server 2012 enables administrators to deploy a highly resilient DHCP service to support a large enterprise without the challenges of setting up Failover Clustering. The main points to remember are…

  • Provide DHCP service availability at all times on the enterprise network.
  • If a DHCP server is no longer reachable, the DHCP client is able to extend the lease on its current IP address by contacting another DHCP server on the enterprise network.
  • DHCP failover is not supported for more than two DHCP servers. The failover relationship is always comprised of two DHCP servers.
  • For DHCP failover to function correctly, time must be kept synchronized between the two servers in a failover relationship. Time synchronization can be maintained by deployment of the Network Time Protocol (NTP) or any alternate mechanism. When the failover configuration wizard is run, it will compare the current time on the servers being configured for failover. If the time difference between the servers is greater than one minute, the failover setup process will halt with a critical error instructing the administrator to synchronize the time on the servers

The DHCP server failover feature provides the ability to have two DHCP servers provide IP addresses and option configuration to the same subnet or scope, providing for continuous availability of DHCP service to clients. The two DHCP servers replicate lease information between them, allowing one server to assume responsibility for servicing of clients for the entire subnet when the other server is unavailable. It is also possible to configure failover in a load-balancing configuration with client requests distributed between the two servers in a failover relationship.

DHCP failover in Windows Server 2012 provides support for a maximum of two DHCP servers, and the failover relationship is limited to IPv4 scopes and subnets. Network nodes using Internet Protocol version 6 (IPv6) typically determine their own IPv6 address using stateless IP auto configuration. In this mode, the DHCP server delivers only the DHCP option configuration, and the server does not maintain any lease state information. A high availability deployment for stateless DHCPv6 is possible by simply setting up two servers with identical option configuration. Even in a stateful DHCPv6 deployment, the scopes do not run under high address utilization, which makes split scope a viable solution for high availability.

DHCP Failover Architecture

You can have 2 modes of DHCP Failover

  • Hot Standby
  • Load Sharing

Hot standby mode

In hot standby mode, 2 servers operate in a failover relationship where an active server is responsible got leasing IP addresses and configuration information to all clients in a scope or subnet. The secondary server assumes this responsibility if there primary server becomes unavailable. A server is primary or secondary in the context of a subnet. For instance, a server that has the role of a primary for a given subnet could be a secondary server for another subnet

Hot standby mode of operation is best suited to deployments where a central office or data center server acts as a standby backup server to a server at a remote site, which is local to the DHCP clients (ex: hub and spoke deployment). In such deployments, it is undesirable to have a remote standby server service any clients unless the local DHCP server becomes unavailable. The figure below is an example of a hub and spoke deployment

Load Sharing Mode

In a load sharing mode deployment, which is the default mode of operation, the two servers simultaneously serve IP addresses and options to clients on a given subnet. The client requests are load balanced and shared between the two servers.

The load sharing mode of operation is best suited to deployments where both servers in a failover relationship are located at the same physical site. Both servers respond to DHCP client requests based on the load distribution ratio configured by the administrator

DHCP1

Instructions

  • First of all we need to install DHCP on the first of the two DHCP Servers
  • Open Server Manager and click Add Roles and Features

DHCP2

  • Select Installation Type > Choose Role based or Feature based installation

DHCP3

  • Select Destination Server

DHCP4

  • Select Server Role

DHCP5

  • Select Features

DHCP6

  • Click Next on the Select Features Page

DHCP7

  • Click Next on the DHCP Server Page

DHCP8

  • Click Next and Install

DHCP9

  • Once finished click Complete Configuration

DHCP10

  • Before DHCP can be used as a Failover partner, it must be authorised in Active Directory
  • On the Post Installation Task screen click Next

DHCP11

  • On the Authorisation screen, add your DHCP User or use the Administrator

DHCP12

  • Click Commit and check the results

DHCP13

  •  Now you need to do exactly the same steps on your second DHCP Server
  • Go to the first DHCP Server and on the Server Manager menu bar, click Tools and then click DHCP. THE DHCP console opens.
  • In the DHCP console tree, navigate to IPv4. Right-click IPv4 and then click New Scope. The New Scope Wizard opens.

DHCP14

  • Click Next and then type a name for the new scope next to Name DACMT Scope

DHCP15

  • Click Next and then in IP Address Range, type 10.1.1.247 next to Start IP address, type 10.0.0.249 next to End IP address, and type 24 next to Length. The value of Subnet mask will change automatically to 255.255.255.0

DHCP16

  • Click Next, and then don’t add anything in Add Exclusions and Delay.

DHCP17

  • Click Next and then in Lease Duration under Limited to enter 0 Days, 0 Hours, and 2 Minutes. This very short lease duration will simplify the DHCP failover demonstration.

DHCP18

  • Click Next to DHCP Options

DHCP19

  • Add in your Router name and click Add

DHCP21

  • In Domain Name and DNS Servers, verify that the Parent domain is dacmt.local and 10.1.1.160 is listed as the only DNS server. (Check your own Domain and DNS Server here!)

DHCP22

  • Ignore WINS Servers for now

DHCP23

  • Select yes to activate the Scope now

DHCP24

  • In the DHCP console tree, right-click dhcp2.contoso.com, and then click Authorize.
  • Refresh the view in the DHCP console and verify that your DHCP Server is authorized and that the Scope is active.

DHCP25

  • Next we are ready to configure Failover
  • On your second DHCP Server where you have activated and specified the scope, right click the scope and select Configure Failover

DHCP26

  • The Failover wizard will open. Click Next

DHCP27

  • Specify the partner server you want to use. Click Add

DHCP28

  • The next screen is the Create a Failover Relationship and this is where we have the different modes. (Load Balance or Hot Standby)
  • I am going to choose Load Balanced for now

DHCP30

  • Type a shared secret for this failover relationship next to Shared Secret
  • Change the value next to Maximum Client Lead Time to 0 hours and 1 minute
  • The Maximum Client Lead Time (MCLT) is additional time provided to a DHCP client after expiration of a DHCP lease. The MCLT is transmitted from the primary to the secondary server in the CONNECT message, and is the maximum amount of time that one server can extend a lease for a client beyond the time known by the partner server.
  • In a production environment, you should use a longer MCLT, such as 1 hour.
  • So we should now look like the below screen

DHCP31

  • Click Next and review the settings

DHCP32

  • Check everything ran successfully in the box which pops up below

DHCP33

  • On your first DHCP Server, refresh the DHCP console and verify that the same DHCP scope configuration that is present on the second DHCP Server is now present on here

DHCP34

  • Voila, you have now set up one of the modes of DHCP Failover 🙂

Adding Excel 2010 Add-ins for all users on an RDS Farm

plus sign

The Requirements

To make 2 x Excel 2010 Add-ins load automatically whenever anyone logged into Excel 2010 on any RDS Server in the farm using their roaming profile

  • 4 x Windows 2008 R2 Remote Desktop Servers in an RDS Farm
  • 1 x Excel 2010 installed on each RDS Server
  • 2 x Excel 2010 Add-ins
  • Roaming Profiles
  • For testing purposes the D Drive was a trusted location in Excel (Via Group Policy)
  • For testing purposes, macros were enabled without prompting (Via Group Policy)

This was actually more complicated than it first looked. We found that on a per user basis when they manually add the add-ins through Excel then it retained the settings through the roaming profile no matter what server in the farm they were on which was great but we wanted to take the user aspect out of it

Adding Excel Add-ins (Unautomated)

  • Open Excel
  • Click File > Options > Add-ins

Excel Add-ins2

  • Click Go and you will see the default add-ins which come with Excel

Excel Add-ins3

  • Browse to your Add-ins and select them
  • They should then show up

Excel Add-ins5

  • If you have a look in the registry then you will see the add-ins under the following paths. Note the first Add-in is called OPEN, the second is called OPEN1 and so on
  • HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Excel\Options\OPEN
  • HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Excel\Options\OPEN1

Excel Add-ins1

What we tested to start with

We thought it might be worth a try putting the RDS Server into Install mode and installing the Add-ins

Excel Add-ins6

  • Open Excel > File > Options > Add-ins > Go Install the Add-ins under an Admin account and then close Excel
  • Come out of Install Mode

Excel Add-ins7

  • But this didn’t work for any new users logging into the server either. The Add-ins did not appear but apparently this did work for someone who posted in a forum
  • Next we had a look to see if we could use Group Policy. Note you have to download and install the relevant Microsoft Office Templates so you can see them in GPME. See below pic

Excel Add-ins8

  • But lo and behold there was not anything relating to Excel Add-ins or exactly what we needed. Apparently you are meant to be able to customise every aspect of Excel through GP but it sometime requires specialist knowledge and programming experience which we didn’t particularly want to get into.
  • Just as a note, we searched the web for a simple resolution to this and although you can find people with the same problem, we couldn’t find anyone who had this working
  • Next we will show you how we got this working via 3 methods. There may be other better solutions but these worked for us!

Working Solution 1 (Write a batch script containing reg syntax)

Bear in mind that this will be a brand new user logging into a server and opening Excel so we need to take into account that some of the necessary Office registry keys will not exist and we are using Office 2010.

The first thing we thought we could would be to write a short batch script which added the keys into the registry as per next 6 lines.

Note: If writing the below into Notepad then DO NOT USE WORD WRAP and note the “\” which enclose any path which has spaces

  • REG ADD HKEY_CURRENT_USER\Software\Microsoft\Office\ /f
  • REG ADD HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\ /f
  • REG ADD HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Excel\ /f
  • REG ADD “HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Excel\ \Options\ /f
  • REG ADD HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Excel\Options\ /v OPEN /t REG_SZ /d “\”D:\Program Files (x86)\ibm\cognos\tm1\bin\tm1p.xla”\” /f
  • REG ADD HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Excel\Options\ /v OPEN1 /t REG_SZ /d “\”D:\Program Files (x86)\ibm\cognos\tm1\bin\ManCalcv2.xlam”\” /f
  • Here is what it looks like

regadd script

  • You can the save this as a .bat file and load it into a Group Policy to run at Startup or User Logon

The Second solution (PowerShell Script)

I found this PowerShell Script which adds Excel Addins. Thanks to Jan Egil Ring

http://poshcode.org/1811

  • Copy the script into a notepad file
  • Change the name of your Add-in (Circled below)
  • Change the Path to your Add-in (Circled below)
  • Save script with a .ps1 suffix

PowerShellexcel

  • Next go to Group Policy
  • Create a new User Group Policy
  • Navigate to User Configuration > Windows Settings > Scripts (Logon/Logoff)

powershell02

  • Double click on Logon
  • Click on PowerShell Scripts

powershell03

  • Click Add

powershell04

  • Click Browse
  • From here, I click Add, and click Browse. The Add a Script dialog appears. The Browse button opens a Windows Explorer window that is centered on the SysVol share for the domain. I then dragged and dropped my tm1p.ps1 script into the Logon script folder (SysVol Share)

powershell05

  • You should then see your script as per below screenprint

powershell06

  • Click Apply and OK
  • Go to the scope of the Policy and make sure the users or groups are selected for the policy
  • Open cmd.exe and type gpupdate /force
  • Try logging on as a brand new user to the server and see if the script runs and adds your Excel Add-in

The third Solution (Creating a Macro enabled Excel Template)

Thanks to Nicholas Cohen for providing this information

  • Open Excel 2010 on one of your RDS Servers
  • Press ALT F11 to open Visual Basic for Applications
  • Right click on VBAProject (Book1) and select Insert > Module

Excel Add-ins9

  • You will then need to copy and paste the following code into the module box

Sub InstallAddIn(strFileName As String)
Dim AI As Excel.AddIn
Set AI = Application.AddIns.Add(Filename:=strFileName)
AI.Installed = True
End Sub

Sub Auto_Open()

‘replace stuff in quotes with the network path to the add-in
‘this path obviously must be accessible by the user
InstallAddIn (“D:\Program Files (x86)\ibm\cognos\tm1\bin\tm1p.xla”)
InstallAddIn (“D:\Program Files (x86)\ibm\cognos\tm1\bin\ManCalcv2.xlam”)

‘replace below code with the name of the macro that you want to run when it’s open. You need to know names of what’s inside the Add-in to put here which is why this is commented out as an example but it will run anyway with the below path
‘code/routines in add-in tm1p.xla
‘code/routines in add-in Mancalcv2.xlam
‘repeat ad-infinitum….

End Sub

  • It should look like the below

Excel

  • Now go back to Excel and do File > Save As >
  • Give it a name and save it as an Excel Macro-Enabled Template to the desktop or wherever convenient

Exceladdins21

  • Now the next task will be to put this Excel Template into the users roaming profile path under the XLSTART Folder which in most people’s case will be either of these 2 paths
  • \\server\Profiles\AppData\Roaming\Microsoft\Excel\XLSTART
  • \\server\Home\AppData\Roaming\Microsoft\Excel\XLSTART
  • Note: We redirect our users AppData folder to their home folder
  • This can then be scripted and put in a Group Policy

Exceladdins22

  • Next I’ll look at a script to do this but I haven’t got round to it yet as the PowerShell script seemed neater.

The Fourth Solution

This next solution was an added requirement to adding Excel Add-ins in a Terminal Server environment.

We had developers who logged into 2 different Terminal Server Farms and used different add-ins on each one. What we found is that the above scripts would sometimes overwrite existing add-ins when swapping from one farm to the next so we needed a script which checked if any of the Excel OPEN keys had values to start with, ignore them and add the Excel add-ins to the next available OPEN Key

Thanks very much to oBda of Experts Exchange for this script.

@echo off
setlocal enabledelayedexpansion
set AddinList[1]="D:\Program Files (x86)\ibm\cognos\tm1\bin\tm1p.xlam"
set AddinList[2]="D:\Program Files (x86)\ibm\cognos\tm1\bin\ManCalcv.xlam"
set Key=HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Excel\Options
set Quiet=0
set LastIndex=10
for /f "tokens=1* delims==" %%a in ('set AddinList[') do (
	if %Quiet%==0 echo Processing '%%b'
	set Value=
	set FoundAt=
	set Data=%%b
	set CompareData=!Data:"=!
	for /l %%i in (0, 1, %LastIndex%) do (
		if %%i==0 (set TestValue=OPEN) else (set TestValue=OPEN%%i)
		reg.exe query "%Key%" /v "!TestValue!" >NUL 2>&1
		if errorlevel 1 (
			if "!Value!"=="" (
				if %Quiet%==0 echo !TestValue! ... free.
				set Value=!TestValue!
			)
		) else (
			if %Quiet%==0 echo !TestValue! ... already used.
			for /f "tokens=2*" %%o in ('reg.exe query "%Key%" /v "!TestValue!"') do set CompareDataExisting=%%p
			set CompareDataExisting=!CompareDataExisting:"=!
			if /i "!CompareData!"=="!CompareDataExisting!" set FoundAt=!TestValue!
		)
	)
	if "!Value!"=="" (
		echo ERROR: Unable to find an empty index in the range of 0..%LastIndex%
		goto :eof
	)
	if "!FoundAt!"=="" (
		reg.exe add "%Key%" /v "!Value!" /t REG_SZ /d "!Data:"=\"!" /f >NUL
		if errorlevel 1 (
			echo ERROR: Could not create value '!Value!' with data '!Data!' at '%Key%'
		) else (
			if %Quiet%==0 echo Value successfully added.
		)
	) else (
		if %Quiet%==0 echo Found data in '!FoundAt!', nothing added.
	)
)

Installing the Microsoft Remote Desktop Gateway Role Service

gw

What is Microsoft Remote Desktop Gateway?

A Remote Desktop Gateway (RD Gateway) server is a type of gateway that enables authorized users to connect to remote computers on a corporate network from any computer with an Internet connection. RD Gateway uses the Remote Desktop Protocol (RDP) along with the HTTPS protocol to help create a more secure, encrypted connection.

In earlier versions of Remote Desktop Connection, people couldn’t connect to remote computers across firewalls and network address translators because port 3389—the port used for Remote Desktop connections—is typically blocked to enhance network security. However, an RD Gateway server uses port 443, which transmits data through a Secure Sockets Layer (SSL) tunnel.

Benefits of an RD Gateway server

  • Enables Remote Desktop connections to a corporate network from the Internet without having to set up virtual private network (VPN) connections.
  • Enables connections to remote computers across firewalls
  • Allows you to share a network connection with other programs running on your computer. This enables you to use your ISP connection instead of your corporate network to send and receive data over the remote connection.

How does RD Gateway work?

When a client makes a connection, RD Gateway first establishes SSL tunnels between itself and the external client. Next, RD Gateway checks the client’s user (and optionally the computer) credentials to make sure that the user / computer are authorized to connect to RD Gateway. Then RD Gateway makes sure the client is allowed to connect to the requested resource. If the request is authorized then RD Gateway sets up an RDP connection between itself and the internal resource. All communication between the external client and the internal endpoint goes through RD Gateway

Connections to RD Gateway use the RDGSP protocol. RDGSP creates two SSL tunnels (one for incoming data and one for outgoing data) from the external client to RD Gateway. Once the tunnels are established the client and RD Gateway establish a main channel over each tunnel. Data between client and the destination machine is sent over the channels and RD Gateway sits in the middle proxying the data back and forth

RD Gateway2

RDGSP uses a transport to create the channels.  In Windows Server 2008 R2, RDGSP used the RPC over HTTP transport. RPC over HTTP is still available for down-level RDP clients, but whenever available, RDP 8.0 clients will use the new and much more efficient HTTP transport. The difference is this: RPC over HTTP makes RPC calls for every data transfer to and from the client. This adds significant CPU overhead. The new HTTP transport does not have this overhead so it’s possible to accommodate up to twice as many RDP sessions on the same hardware.

Important Notes about Certificates

The certificate must meet these requirements:

  • The name in the Subject line of the server certificate (certificate name, or CN) must match the DNS name that the client uses to connect to the TS Gateway server, unless you are using wildcard certificates or the SAN attributes of certificates. If your organization issues certificates from an enterprise CA, a certificate template must be configured so that the appropriate name is supplied in the certificate request. If your organization issues certificates from a stand-alone CA, you do not need to do this.
  • The certificate is a computer certificate.
  • The intended purpose of the certificate is server authentication. The Extended Key Usage (EKU) is Server Authentication (1.3.6.1.5.5.7.3.1).
  • The certificate has a corresponding private key.
  • The certificate has not expired. We recommend that the certificate be valid one year from the date of installation.
  • A certificate object identifier (also known as OID) of 2.5.29.15 is not required. However, if the certificate that you plan to use contains an object identifier of 2.5.29.15, you can only use the certificate if at least one of the following key usage values is also set: CERT_KEY_ENCIPHERMENT_KEY_USAGE, CERT_KEY_AGREEMENT_KEY_USAGE, and CERT_DATA_ENCIPHERMENT_KEY_USAGE.
  • The certificate must be trusted on clients. That is, the public certificate of the CA that signed the TS Gateway server certificate must be located in the Trusted Root Certification Authorities store on the client computer

Checklist to install the Remote Desktop Gateway Role

  1. Install the Remote Desktop Gateway role service.
  2. Obtain a certificate for the RD Gateway server.
  3. Create a Remote Desktop connection authorization policy (RD CAP)
  4. Create a Remote Desktop resource authorization policy (RD RAP)
  5. Configure the Remote Desktop Services client for RD Gateway.

Install the Remote Desktop Gateway Role

  • Open Server Manager and select Add Roles and Features. You will get the Before you begin page. Click Next

rdgateway1

  • Select Installation Type. Choose Role based or Feature based Installation

rdgateway2

  • Select Destination Server

rdgateway3

  • Select Server Roles. Choose Remote Desktop Services

rdgateway4

  • Click Next on Features

rdgateway5

  • Click Next on Remote Desktop Services Page
  • On the Select Role Services, choose Remote Desktop Gateway

rdgateway7

  • Click Add Features

rdgateway8

  • On the Network Policy and Access Screen, click Next

rdgateway9

  • Leave Network Policy Server checked

rdgateway10

  • Confirm Installation Selections and click Install

rdgateway11

  • Next launch Remote Desktop Gateway Manager by going to Server Manager > Tools > Terminal Services > Remote Desktop Gateway Manager

rdgateway12

  • Select the Servername and you will see several messages to further configure this server

rdgateway13

  • Select View or modify certificate properties
  • You do not need a certification authority (CA) infrastructure within your organization if you can use another method to obtain an externally trusted certificate that meets the requirements for TS Gateway. If your company does not maintain a stand-alone CA or an enterprise CA and you do not have a compatible certificate from a trusted public CA, you can create and import a self-signed certificate for your TS Gateway server for technical evaluation and testing purpose
  • I am going to use a Self-Signed Certificate. Select Create and Import Certificate.

rdgateway14

  • The following screen will come up

rdgateway15

  • It will pop up with a confirmation box below

rdgateway16

  • In the Server Farm tab, enter the name of the Remote Desktop Gateway Server and click Add
  • The add the second Remote Desktop Gateway Server etc if you have one

rdgateway17

  • Now have a look at the other settings
  • Look at General

rdgateway20

  • Look at Transport Setttings

rdgateway18

  • Next is RD CAP Store

rdgateway19

  • Look at Messaging

rdgateway21

  • Look at SSL Bridging

rdgateway22

  •  Look at Auditing

rdgateway23

  • Now we need to define Connection Authorization Policy. Select Create connection authorization policy.

rdgateway24

  • Click Requirements and add your User Groups or Computer Groups

rdgateway25

  • Click on Device Redirection

rdgateway26

  • Click on Timeouts

rdgateway27

  • Next go back to the main console and create a resource authorization policy

rdgateway28

  • Click User Groups and add a group or groups

rdgateway29

  • Click Network Resource

rdgateway30

  • Click Allowed Ports

rdgateway31

  •  Complete
  • Now test your mstsc access!

Useful Step by Step Guide from Microsoft

http://technet.microsoft.com/en-us/library/cc771530%28v=ws.10%29.aspx

PDF Guide

TS Gateway Step by Step Guide

Useful Notes about Certificates

http://go.microsoft.com/fwlink/?LinkID=74577

Useful RD Gateway Firewall Blog

http://blogs.msdn.com/b/rds/archive/2009/07/31/rd-gateway-deployment-in-a-perimeter-network-firewall-rules.aspx

Resolving Issues

  • You must make sure you have the correct certificates. You must use a certificate with a SAN (Subject Alternative Name) and this must match the internal FQDN.

RDWEB4

  • You must make sure you have set up the correct RAPs and CAPs
  • You used password authentication but the TS Gateway server is expecting smart card authentication (or vice versa
  • Make sure you haven’t limited connections
  • Check DNS for individual servers and RDS Farms
  • Check Event Viewer on the Gateway Server > Event Viewer > Applications and Services Logs > Microsoft > Windows > TerminalServices-Gateway > Operational
  • You may have a Port assignment conflict. You can use netstat tool to determine if port 3389 (or the assigned RDP port) is being used by another application on the Remote Desktop server
  • Users must be a member of the Remote Desktop Group on the servers they want to connect to

If using RD Gateway with RD Web Access then it can be useful to check the following

  • If you are using a Terminal Server Farm, you need to make sure the Start > All Programs > Administrative Tools >  Remote Desktop Services > Remote Desktop Session Host Configuration has the following set for Networking

RDWEB1

RDWEB2

  • Sometimes you may need to check NIC Order in Network Connections

RDWEB3

  • In RemoteApp Manager check you have a FQDN in your RemoteApp Deployment Settings and the port is correct
  • Check RD Gateway Settings are correct. Note I have blanked out the FQDN but this should be the case in these fields

RDWEB5

  • Make sure on each individual RDS Server in a farm that you have the Connection Broker Server and the RD Web Access Server.

Using Registry Keys using REG Commands

Cog

Using the REG Commands

There are a lot of options and switches for the REG command. There are options to query, add, and delete keys, subkeys, and value names

reg add 2

The reason I have blogged about this is that we had to set some keys at my work and this works quite nicely if you write a bat script containing your relevant REG commands and add this to a GPO at User Logon

reg add

Writing a quick bat script

This is an example of something quick and easy to use

  • Open Notepad
  • Type Echo Off at the top to stop users seeing the script scrolling through
  • Look at the script below and see some of the switches and where to put quote marks etc

TestApp

  • The various switches you can use are listed in the screeprint above
  • You can then put this script for example on the C:\ of the server
  • Open Group Policy Management and create a new GPO
  • Navigate to User Configuration > Policies > Administrative Templates > System > Logon > Run these programs at user logon

app2

  • Click Show and type in the name of your script

app1

  • Link GPO to the Computer OU you need this applied to
  • Finish

Running a Hyper V VM within VMware vSphere 5.5

Windowsicon

The Issue

I wanted to set up 2 Microsoft Server 2012 Hyper V Hosts within my VMware 5.5 test environment but found that when it came to going through the Add Features > Hyper V component and selecting Hyper V that I received the message below

HypervErrror

The Fix

  • Shutdown the VM
  • Go into the VMware Datastore and locate your Hyper V Folder
  • You need to locate the .vmx file and download it to your desktop

hyperverror2

  • Open the vm.vmx file in Notepad and you will need to add the following 3 strings to the VM.vmx file
  • hypervisor.cpuid.v0 = “FALSE”
  • mce.enable = “TRUE”
  • vhv.enable = “TRUE”
  • See file screeprint below

hyperverror4

  • Power the machine on
  • Open Server Manager
  • Add Roles and Features
  • Select Hyper V

hyperverror5

  • You now should be able to install Hyper V