(Post courtesy Anil Malekani)
The Software Catalogue portal is a cool new feature in System Center Configuration Manager 2012. Administrators can publish applications for end users, and optionally they can enforce authorization before actual deployment of the application. I tried to configure the feature in the release candidate of Configuration Manager 2012 and captured screenshots at each important step.
Before you start to configure the Application Catalogue, look for prerequisites at the following TechNet link
Prerequisites for Application Management in Configuration Manager
Now, Right click on one of the SCCM 2012 Primary site systems, to add new Role.
Select Application Catalog Web Service Point and Application Catalog Website Point
You may specify a name for the web application
Provide Organization name and web theme.
That done, you have the website ready but you still need to publish applications for users.
1. Publish Application to Catalogue, from application properties > Application Catalog tab.
2. Deploy application to all users. Make it available and (optionally) set "approval required" if users requests application .
Finally, define Application Catalog synchronization frequency. Right click on site server and go to "Site Maintenance" option. Scroll down to the bottom of the list and select Update Application Catalog Tables option. In to properties define an interval in minutes.
Configure Application Catalogue update setting
User Experience
When a users opens the application catalog website, he can see a list of published applications and request application.
If an application requires approval before deployment, the administrator will see a pending approval request under Application Management. Administrators can either approve or deny the deployment request and also write comments.
Once approved, the client will see the following on their workstation
(Post courtesy Kapil Hudiya)
In order to make sure that your Lync server is running successfully with all the required features, I want to share my experience of troubleshooting Lync Server 2010 and client connectivity
If you have followed best practices and configured Lync 2010 according to Microsoft recommendations, it is less likely that you will run into errors. Common factors for the errors that I have encountered include network configuration steps (such as DNS, Firewall, etc.) and other configuration steps such as certificates, integration with Exchange Servers.
I would say 95% of the issues that I have encountered are due to improper configuration. For quick resolution, we have to first identify the issue and that’s very important. So let’s first see how we can identify and solve Lync client connectivity issues:
Lync Client Connectivity issues Internal and Externally.
If it is Client connectivity issues to Front end server internally then you should have following information:
1) Check if users trying to login is enabled in Lync server.
2) Go to Settings –> Tools –> Options
Then select Advanced Connection Settings:
3) Now let’s Check DNS records:
On DNS server, go to Start-> Administrator tools -> DNS -> Forward lookup Zone -> contoso.com (Domain name)-> _TCP . See if _sipinternalTLS record is created.
If yes then check if it matches following settings. If no then create new record by right click on zone ->other new records -> SRV.
Domain will be Contoso.com
The host offering this service should be pool name of Front End Server. If Director Servers are installed then the Director Server pool name should be entered.
More details available at the following TechNet article: Determining DNS Requirements
4) The last option you have to check is Certificates.
Install the Root certificate of the internal CA in trusted root certificate of the computer.
Open Internet Explorer -> in address bar enter Internal CA FQDN followed by /certsrv.
Example: DC1.contoso.com/certsrv.
a) Under select task: Download CA certificate, certificate chain, or CRL.
b) Download CA certificate chain, save the file on desktop.
c) Now, Start->Run -> type MMC -> Under File -> Add/remove snap-in -> select certificate under Add remove snap-ins , select Add, computer account ,next and then Finish. Then click ok to close the window.
d) Under Console 1 -> Expand Certificates ->Trusted root certificate -> certificate -> right click on certificate-> All Task and then click Import.
e) On Certificate Import Wizard, select next, under File name select Browse and select the Root certificate, then next, In certificate store select next, then Finish.
If you are experiencing Client connectivity issues to the Lync Edge server externally (Remote connectivity) then you should have following information:
1) Follow first and second steps mentioned above.
2) Now let’s Check public DNS records and network configuration:
a. _sip._tls. Contoso.com
b. A record for Access Edge Server .
http://technet.microsoft.com/en-us/library/gg412787.aspx
3) Let’s Check the topology Builder:
4) Certificates:
Check if the public Certificate common name is same as access edge server name published in Public DNS.
Without Hardware Load balancer:
http://technet.microsoft.com/en-us/library/gg398519.aspx
5) Firewall Ports: Check if required Firewall ports are open by Port Query Tool (http://support.microsoft.com/kb/310099)
6) A few more steps …..
a. On Lync Front End, Check the SQL (CMS) replication status by using the following Lync PowerShell cmdlet:
get-csmanagementstorereplicationstatus
the uptodate: option should be true. If not, ports are blocked or there are other Lync edge Server deployment issues.
b. Make sure the user is allowed for remote access by remote access policy.
7) Now check with the Remote Connectivity Analyzer at https://www.testocsconnectivity.com/ to verify if you get Green\
(Post courtesy Manoj Ravikumar Nair, who you can follow on his excellent blog at http://www.powershell.ms)
What? Are you kidding me? I never knew we could automate Remote Desktop Services using PowerShell. But, yes we can. You can almost automate everything within your Remote Desktop Services Infrastructure using Windows PowerShell.
So the burning question is, when should I use PowerShell and when should I prefer using a GUI?
To explain this, let’s discuss common scenario. You have about 10 Remote Desktop Session Host Servers in your Farm. You would like to do an inventory of the RemoteApps running on each of these servers. Now ideally, it is recommended to run the same RemoteApps on RDSH Servers running in a Farm. But let’s take an exception here. What would be your approach in this case?
One way to tackle this is to use the RemoteApp Manager, connect to each RDS Server and check the RemoteApps running on it. Well, nothing very complex about this approach. But imagine the amount of time you’d spend on doing this! Consider there are more than 10 Servers participating in a Farm. You’d be just:
The other way to deal with this scenario is, yes, you guessed it right, use PowerShell.
Ask yourself a question: If you were in charge of a team of IT administrators, which ones would you want in your team?
The ones who need several minutes to click their way through a GUI for each task?
OR
The ones who can perform tasks in a few seconds after automating them?
It’s an obvious choice. PowerShell has given the term “administration” a new definition and very soon who will see the Microsoft IT Administration world split into two worlds:
Ones who would continue to ignore PowerShell, use GUI and continue to use GUI even if it results in skipping their meals to get the tasks done.
Ones who already are comfortable with the GUI and use it to perform one time tasks while harness PowerShell to automate bulk operations.
Now that I have set the background on “Why to use PowerShell?”, let me on take you to a seven part journey to automate your existing RDS Environment using PowerShell.
Milestone 1 – Installing Remote Desktop Role Services
Milestone 2 – Configuring Remote Desktop Session Host using the RDS Provider for PowerShell
Milestone 3 – Configuring Remote Desktop Connection Broker
Milestone 4 – Configuring Remote Desktop Farms
Milestone 5 – Configuring Remote Desktop Gateway
Milestone 6 – Configuring Network Load Balancing for RD Gateway using PowerShell
Milestone 7 – Using Best Practices Analyzer to review our RDS Infrastructure
Milestone 8 – Using additional resources
Alright, so let’s dive straight into the first part, i.e. Installing RDS Roles using PowerShell. Let’s be immediately effective.
To install any role or feature on a Windows Server 2008 R2 Server, we will leverage the Add-WindowsFeature command of the ServerManager Module. This Command is not installed by default but we can import the ServerManager module in the current PowerShell RunSpace.
To import the ServerManager module, use the following command
Import-Module ServerManager
To see what all commands are being loaded as a part of the import process, you can use the –verbose parameter
Import-module ServerManager –verbose
Because the names of the Roles, Role Services and Features are case sensitive, we will first get the names of the Roles Services, the way PowerShell understands them by using the command below
Get-WindowsFeature –Name *RDS*
The names are case-sensitive, so while using the Add-WindowsFeature, ensure that you use the correct case as shown above.
If you used the Server Manager module to install a Role, you will notice that while installing a Role, if there are any dependent features, the Server Manager automatically prompts you for installing them as well. In PowerShell, we can achieve this by using the –IncludeAllSubFeature parameter of the Add-WindowsFeature.
The best part about PowerShell is the –whatif parameter. When you use this parameter with any command that attempts to make changes to your system, PowerShell will notify you of the changes the command will make but actually doesn’t implement them. In this way, you can validate the changes being made even before making them. Let’s see this in action by running the following command
Add-WindowsFeature –Name RDS-RD-Server –IncludeAllSubFeature -WhatIf
Note that, PowerShell tells you that performing this action would install the Remote Desktop Session Host Role on the server and a restart would be required.
Let’s run the same command again but this time we will omit the –whatif parameter so that the role is actually installed.
To restart the server after the role is installed, you can append the –Restart parameter to automatically restart the server once the role is installed.
Once the Server has rebooted, run the Get-Module –ListAvailable command to see the RDS PowerShell Module installed as part of the RD Session Host Role installation.
Let’s import the module of RDS PowerShell and see what all commands are available within it.
Import-Module RemoteDesktopServices
Get-Command –Module RemoteDesktopServices
What!! Just 7 commands? How can you automate my RDS Infrastructure using just seven commands? Also note that I am using Windows Server 2008 R2 SP1, so I get additional commands that work with Virtual GPUs (RemoteFX is only available with Server 2008 R2 SP1)
RDS PowerShell adds a PS Provider (RDS:) that allows you to access your Remote Desktop Services Configuration like a file system. This is a known fact. To access the RDS Provider, run the following command:
Get-PSProvider
Oops! the name got chopped off. Let’s pipeline Get-PSProvider to Format-Table to auto fit the contents within the PowerShell Runspace.
To access the RDS PS Drive, we will change directory to it.
cd RDS:
To view the subdirectories with the RDS drive, run the dir or the Get-ChildItem (note that dir is an alias for Get-ChildItem)
We will tackle the RDSConfiguration and the RemoteApp Containers one by one.
RDSConfiguration
To access the RDSConfiguration container, change directory to it. You just need to type in the first few characters of the container name that makes it unique and hit the tab key to auto complete the name for you and as well as provide its absolute path.
The command commands you would use with the RDS Provider are as follows
Dir
Get-ChildItem {which is same as dir}
Get-item
Set-Item
Remove-Item
New-Item
To access the sub contents of the RDSConfiguration, let’s do a dir on RDSConfiguration
Let’s analyze this content a bit.
The first column displays the name of the container or setting. You can determine whether a particular item is a container or an individual setting by looking at the Type Column (the second column). Containers will have further subdirectories whereas the settings are leaf objects and will not have any further hierarchy below it.
The third column is the CurrentValue which as the name suggests indicates the current value of the setting. As you can see in the screenshot above, UserLogonMode is currently set to 0. What does 0 mean? Park that question for a moment and we will figure that out once we get into configuring settings.
The fourth column is GP which stands for Group Policy. This indicates whether the current setting is configured via RDS Group Policies or not.
The Fifth column is PermissibleValues which as the name suggests, indicates the permissible values that the configuration item can accept.
The Last column is PermissibleOperations that indicates current PowerShell cmdlets that are permitted to be used in the Configuration Item.
Note that this information is similar to what you see in the Remote Desktop Session Host Configuration Console under edit settings.
Let’s browse Connections and further drill down RDP-TCP.
Now, it’s time to set a particular configuration item.
To get more information about any leaf or configuration setting, just use the following syntax
Dir <setting name> | Format-List *
For example, dir .\ConnectionStatus | Format-List *
From the screenshot above, we can see that ConnectionStatus defines the “status of the connection” as given in the description. Setting it as 0 disables the setting and setting it as 1 enables it. By default, it is enabled.
We will take a step further and access the content of the LogonSettings Directory. Here, we will set the ClientLogonInfoPolicy to 0, which will ensure that the server’s connection will override the user’s connection settings
By default, it is set to 1 which means that the User’s Connection Settings will override Server’s connection setting. We can verify it via the GUI as well.
Let’s see the complete information of the ClientLogonInfoPolicy by running the command below:
dir .\ClientLogonInfoPolicy | fl *
Now, let’s set the value to 0 by using the command below:
Set-Item .\ClientLogonInfoPolicy 0
Note that I am running this from the Path RDS:\RDSConfiguration\Connections\RDP-Tcp\LogonSettings
If you running this from any other drive, you can use the –Path parameter and you need to explicitly provide the entire path. I have used this approach to revert the value back to 1.
Set-Item –Path RDS:\RDSConfiguration\Connections\RDP-Tcp\LogonSettings\ClientLogonInfoPolicy 0
To verify, let’s fire up the GUI for the same setting. Wow!, we see that the configuration change has been made. Huraaaaaaaaaaaaaay ! J
To revert it back, we will set the value back to 1. This will ensure that the client settings override the server’s setting
Do not forget to refresh the console. The setting will be in effect only if you refresh the console and explore the properties again
So let me reiterate, you should use the following commands to work your way out with RDS PowerShell
Set-item
New-item
Remove-item
Use the Dir <setting Name> | Format-List * to get information about a particular setting
Installing Role Services Remotely:
How do you install a Role Service, let’s say RD Web Access Remotely. Unfortunately, the Add-WindowsFeature does not have the –ComputerName parameter wherein we can specify the name of the Remote Computer.
However, we do have a workaround in the form of PowerShell Remoting. To enable PowerShell remoting, you need to run the following command
Enable-PSRemoting
I am going to run this command on a remote server named FUJI
This will automatically configure the firewall exceptions and the WinRM (Windows Remote Management) service to allow the server to accept remote commands. Server 2008 R2 has GPOs to configure PowerShell Remoting which I will cover in a different blog post. You can use GPOs to automatically enable PS Remoting on all your server machines so that they can be remotely managed.
Now that I have enabled PS Remoting on FUJI, we will remotely install the RD Web Access Role Component on it.
For the time being, I will use 1:1 Remoting.
New-PSSession –Name FUJIRemote –ComputerName FUJI
Next we will enter the session that was just opened
Enter-PSSession –Name FUJIRemote
If you are able to connect to the session, you should now see the PowerShell to display the name of the computer before the PS Prompt
[fuji]: PS C:\Users\Administrator.POWERSHELL\Documents>
This indicates that you are now connected to the remote session and whatever you do at this prompt will be now performed on the remote server which is FUJI in our case.
The rest is simple. We will follow the same steps that we did to install the RD Session Host Role.
As you can see we were able to install the RD Web Access role on the Remote Server FUJI and PowerShell tells you that the server does not require a reboot after the installation of the RD Web Access. I knew that beforehand and hence didn’t specify the –Restart parameter J
We will verify the same by taking a look the Server Manager on the Fuji Server
This is just one example of PowerShell Remoting. You can also do a 1:Many Remoting wherein you can specify a bunch of computer names in a text file or so and then perform actions on each of those computers.
With this we conclude the first milestone of our Project, i.e. Installing Role Services using PowerShell. We also touch based upon some of the configuration settings.
Next Post: Extending Remote Desktop Services via PowerShell – Part 2
(Post courtesy of Yashkumar Tolia. Steps below are from the Virtual Application Management with Microsoft Application Virtualization 4.5/4.6 and System Center Configuration Manager 2007 R2 White Paper)
Application Virtualization is an important component of the virtualization stack. An important and a vital ingredient in the Virtual Desktop Infrastructure cuisine, it separates out the application from the Operating System. Configuration Manager, on the other hand, is widely used for patching, updating and management of an entire IT infrastructure. The integration of these two technologies gives the freedom of managing the virtualized application and leverages it by rapid deployment of the App-V client.
Configuration Manager includes capabilities to integrate with App-V out-of-the box. Configuration Manager Uses only publicly documented interfaces to interact with the App-V Client software. All integration is implemented with the following methods:
App-V Integration with Configuration Manager is streamlined as Configuration Manager is simply automating tasks that can be done with App-V. Organizations with Configuration Manager already in place or those in the process of implementing Configuration Manager; can implement one infrastructure using a seamless, scalable solution to deliver, report, and manage the application lifecycle from one console.
Configuration Manager and App-V Infrastructure Overview
Configuration Manager and App-V can be integrated to provide a comprehensive deployment and update service for virtual applications. With Configuration Manager, the typical App-V infrastructure is reduced to the App-V Sequencer and Client. Configuration Manager takes the place of the publishing and streaming components in a typical App-V full infrastructure. The following figure illustrates the minimal Configuration Manager and App-V processes and components required to manage virtual applications with Configuration Manager. The App-V Sequencer produces packages that can be distributed via a Configuration Manager infrastructure to the App-V Clients. This eliminates the need for two separate infrastructures to support application deployment. Configuration Manger can be used to deploy both traditional and virtual applications.
Figure 1 – Configuration Manager and App-V Infrastructure
Publishing virtual applications using Configuration Manager requires a simple process to be followed. The following section describes the virtualization (using App-V) and distribution (using Configuration Manager) process.
Process
At a high level, managing virtual applications with Configuration Manager requires applications to be sequenced, published using Configuration Manager Advertisements, and delivered to the end clients. The following minimum process is required to support App-V in a Configuration Manager infrastructure.
Sequencing – The process of taking a physical application and turning it into a virtual application. Configuration Manager requires sequencing applications with an App-V 4.5 or newer Sequencer to create the necessary files for publishing and delivery (Manifest.xml file).
Publishing – The process of provisioning virtual applications to users or computers in Configuration Manager. Configuration Manager utilizes the Site Server components for publishing applications. This process will present the application to the computer before the application assets have been delivered.
Delivery – The process of moving the virtual application assets to the client computers. This is normally referred to as “streaming” in an App-V full infrastructure. Configuration Manager provides two options for delivery of virtual applications (“Streaming” and “Download and Execute”).
Components
Managing virtual applications with Configuration Manger will require an App-V Sequencer for creating packages, a Configuration Manager Site Server, Configuration Manager Distribution Point(s) for delivery of the packages, and Configuration Manager client computers with the App-V Client installed. The following minimum components are required to support App-V in a Configuration Manager Infrastructure.
Microsoft App-V Sequencer – The App-V Sequencer ‘program’ is used to package virtual applications for deployment with Configuration Manager.
Configuration Manager Site Server – A part of the Configuration Manager Site hierarchy, the Configuration Manager Site Server manages virtual application distribution through Configuration Manager Distribution Points to target systems, either as a streaming service, or as a locally delivered package.
Configuration Manager Distribution Point (Distribution Point) – Configuration Manager Distribution Point site roles provide management services such as hardware and software inventory, operating system deployment, and software updates, as well as software distribution of both physical and virtual applications, to Configuration Manager target systems (often referred to as ‘clients’).
Configuration Manager / App-V Clients – Client devices include desktop/laptop PCs, terminal servers and Virtual Desktop Infrastructure (VDI) clients. Configuration Manager Clients that receive delivery of virtual applications from a Configuration Manager infrastructure require both the Configuration Manager Advanced Client and App-V Client software to be installed and configured. The Configuration Manager and App-V Client software work together to deliver interpret and launch virtual application packages. The Configuration Manager Client manages the delivery of virtual application packages to the App-V Client. The App-V Client executes the virtual application on the client PC.
Next Post: Integration of System Center Configuration Manager and App-V (part 2)
(Post courtesy Himankini Shah)
A shared mailbox is a mailbox that multiple users can open to read and send e-mail messages. Shared mailboxes allow a group of users to view and send e-mail from a common mailbox. They also allow users to share a common calendar, so they can schedule and view vacation time or work shifts.
In Office 365, shared mailboxes don’t require a license. But each user who accesses a shared mailbox must have a user subscription license. Users with Exchange Online Kiosk subscriptions can’t access shared mailboxes. Also, shared mailboxes can’t be used to archive e-mail, except for the messages that are actually sent to or received from the shared mailbox
After you create a shared mailbox, you have to assign permissions to all users who require access to the shared mailbox. Users can't sign in to the shared mailbox. They have to sign in to their own mailbox and then open the shared mailbox to which they've been assigned permissions.
Once you have installed and configured Windows PowerShell v2 and Windows Remote Management (WinRM) on your computer (for more information, see Install and Configure Windows PowerShell), you have to connect the Windows PowerShell on your local computer to the cloud-based service to perform tasks in your cloud-based organization.
When you open Windows PowerShell v2 on your computer, you're in the Windows PowerShell session of your local computer. A session is an instance of Windows PowerShell that contains all the commands that are available to you.
The Windows PowerShell v2 session of your local computer, called the client-side session, only has the basic Windows PowerShell commands available to it. By connecting to the cloud-based service, you connect to the Microsoft datacenter's server environment, called the server-side session, which contains the commands used in the cloud-based service.
Connect Windows PowerShell v2 on your local computer to the cloud-based service
1. Click Start > All Programs > Accessories > Windows PowerShell > Windows PowerShell.
2. Run the following command:
$LiveCred = Get-Credential
In the Windows PowerShell Credential Request window that opens, type the credentials of an account in your cloud-based organization. When you are finished, click OK.
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell/ -Credential $LiveCred -Authentication Basic -AllowRedirection
The AllowRedirection parameter enables cloud-based organizations in datacenters all over the world to connect Windows PowerShell to the cloud-based service by using the same URL.
Import-PSSession $Session
A progress indicator appears that shows the importing of commands used in the cloud-based service into the client-side session of your local computer. When this process is complete, you can run these commands.
After connecting to the online services, here's how you can create and configure a shared mailbox for the Printing Services department at learningdesk domain.
Create a shared mailbox: To create the shared mailbox for Printing Services, run one of the following commands:
New-Mailbox -Name "Printing Services" -Alias print -Shared
Set-Mailbox print -ProhibitSendReceiveQuota 5GB -ProhibitSendQuota 4.75GB -IssueWarningQuota 4.5GB
After we create a shared mailbox, we have to assign permissions to all the users who require access to the shared mailboxes. Users can't sign into their shared mailboxes. They have to sign in to their own mailbox and then opened the shared mailbox to which they have been assigned permissions.
In the Exchange Control Panel, create a security group for the staff who need access to the shared mailbox for Corporate Printing Services.
1. Select My Organization > Users & Groups > Distribution Groups > New.
2. Specify a display name, alias, and e-mail address. In this example, we'll use Printing Services Staff, printdg, and printdg@learningdesk.co.in .
3. Select the Make this group a security group check box.
4. In the Ownership section, click Add to add an owner, if necessary.
5. In the Membership section, click Add.
6. In the Select Members page, select the users you want to add. When you are finished, click OK.
7. On the New Group page, click Save. After we create a security group, the membership is closed. When membership is closed, only group owners can add members to the security group, or owners have to approve requests to join the group. Additionally, only group owners can remove members from the security group.
Assign the security group the FullAccess permission to access the shared mailbox To enable members of the Printing Services Staff security group to open the shared mailbox, read e-mail, and use the calendar, run the following command:
Add-MailboxPermission "Printing Services" -User printdg -AccessRights FullAccess
Assign the security group the SendAs permission to the shared mailbox
To enable members of the Printing Services Staff security group to send e-mail from the shared mailbox, run the following command:
Add-RecipientPermission "Printing Services" -Trustee printDG -AccessRights SendAs
It may take up to an hour until users can access a new shared mailbox or until a new security group member can access a shared mailbox. Assign an Exchange Online (Plan 1) or Exchange Online (Plan 2) license to a shared mailbox if you need additional functionality.
Thanks and Regards,
Himankini