You know, those of us who work here at Microsoft only care about one thing: freedom of choice. (Well, OK, two things: freedom of choice, and buying a new Jaguar every time the current one hits the 1,000 mile mark.) For instance, when you install Microsoft Lync Server 2010, we helpfully provide default policies and configuration settings for everything you can think of: dial plans, Address Book servers, conferencing and privacy policies, you name it. That’s fine, but what if you don’t like our default settings? As an example, what if you don’t like the fact that online meetings have a default limit of 200 attendees, or that, by default, call detail records are only kept for 60 days before being purged? No problem: if you don’t like a policy or configuration setting you can either change it or you can create a brand-new one all your own.
It’s all about freedom of choice.
Note. Well, OK: freedom of choice and our Louis Vuitton Manhattan Richelieu shoes, which are practically a steal at just $10,000 a pair.
And yes, that includes shoelaces.
As it turns out, Microsoft Lync Server makes it very easy to create new policies or new collections of configuration settings. For example, creating a new conferencing policy is as easy as calling the New-CsConferencingPolicy cmdlet and giving the policy a new Identity:
New-CsConferencingPolicy –Identity "RedmondConferencingPolicy"
Note that we didn’t include any parameters in our command other than the mandatory –Identity parameter. Because we didn’t include any other parameters that means that the new conferencing policy will use all the default values associated with a conferencing policy. For example, the maximum size of a meeting will be set to 200 people; dial-in conferencing will be enabled; and the maximum video resolution will be set to VGA (640 pixels by 480 pixels). Pretty simple.
Of course, it’s quite possible that we didn’t want to use only default values in our new policy. Maybe we wanted to limit the maximum meeting size to 100 people, or maybe we wanted to disable dial-in conferencing. On the other hand, maybe we did want to use only default values in our new policy. To tell you the truth, it’s kind of hard to know one way or other seeing as how we don’t actually know what those default values are until after the policy is created. Isn’t there some way to determine the default values for a policy or for a collection of configuration settings without having to actually create that policy or collection of settings?
Funny you should ask; we can think of at least two ways you can do this. (Two apparently being our favorite number today.) For one, you could actually – and please don’t snicker – read the help. Yes, we know: no one reads the help (or much of anything else, for that matter). Still, sometimes the product help can actually be, well, helpful.
No, really; we mean it. For example, to retrieve information for all the parameters for a given cmdlet you can use a command similar to this:
Get-Help New-CsConferencingPolicy –Parameter *
And look at the help for just one of those parameters (emphasis added):
Indicates the maximum number of people who are allowed to attend a meeting. After the maximum number of participants has been reached anyone else who tries to join the meeting is turned away with the notice that the meeting is full. The maximum number of participants can be any whole number between 2 and 1000, inclusive; the default value is 200.
Of course, it’s possible that all the other system administrators will make fun of you if they find out you read the help. Which is why we decided to show you another way to determine the default values for a policy or a collection of configuration settings. Want to know the default values for a conferencing policy, without having to resort to reading the … friendly … manual? Then run this command instead:
New-CsConferencingPolicy –Identity "RedmondConferencingPolicy" -InMemory
Admittedly, this command looks like it creates a new conferencing policy, which is exactly what we didn’t want to do. (We just wanted to see the default values for a conferencing policy.) But looks can be deceiving. (For example, the brand-new Jaguar owned by one of the authors looks remarkably like a three-year-old Acura with over 40,000 miles on it.) If you look closely at the preceding command (and, dare we say, if you read all the way to the end of that command) you’ll notice that we tacked on the –InMemory parameter. This parameter ensures that we don’t create an actual policy or collection of configuration settings; instead, -InMemory creates a virtual policy, a policy that exists only in memory and isn’t actually written to the Lync Server database. In other words, it’s a pretend policy, a pretend policy that – because we didn’t supply any additional parameters or parameter values –shows you all the default values of a conferencing policy:
Identity : Tag:RedmondConferencingPolicy
AllowIPAudio : True
AllowIPVideo : True
AllowParticipantControl : True
AllowAnnotations : True
AllowUserToScheduleMeetingsWithAppSharing : True
AllowAnonymousUsersToDialOut : False
AllowAnonymousParticipantsInMeetings : True
AllowExternalUsersToSaveContent : True
AllowExternalUserControl : False
AllowExternalUsersToRecordMeeting : False
EnableDialInConferencing : True
EnableAppDesktopSharing : Desktop
EnableRecording : False
EnableFileTransfer : True
EnableP2PFileTransfer : True
EnableDataCollaboration : True
MaxVideoConferenceResolution : VGA
MaxMeetingSize : 200
AudioBitRateKb : 200
VideoBitRateKb : 50000
AppSharingBitRateKb : 50000
FileTransferBitRateKb : 50000
If you now run Get-CsConferencingPolicy | Select-Object Identity in order to view all the conferencing policies configured for use in your organization, you should see something like this:
Where’s RedmondConferencingPolicy, the policy we just created? Nowhere. That’s because – just like we said – we didn’t create a real policy, just a virtual one. After all, we didn’t want a new conferencing policy, we just wanted to see the default values for conferencing policies. Which we managed to do – and without having to read the help. Whew!
And now if you’ll excuse us, it’s time for lunch. Today we thought we’d try the FleurBurger 5000, a “Kobe burger containing foie gras, a special truffle sauce, and served on a brioche truffle bun with black truffles on the side.” Sure, it’s $5,000 a pop, but, then again, lunch is like the second or third most-important meal of the day.
Besides, we Microsoft people have to spend all our money on something, don’t we?