Re: [msh] Some msh setup questions
- From: "Jeff Jones [MSFT]" <jeffjon@xxxxxxxxxxxxxxxxxxxx>
- Date: Tue, 3 Jan 2006 09:21:13 -0800
I'll try to answer the best I can inline and will get others to follow up
where I don't have good answers. The office has been a bit empty due to the
holidays so it may take a little while to fill in the missing parts.
--
Jeff Jones [MSFT]
Microsoft Command Shell Development
Microsoft Corporation
This posting is provided "AS IS" with no warranties, and confers no rights.
"Thomas Lee" <tfl@xxxxxxxxx> wrote in message
news:6joGaQFeEEtDFAqi@xxxxxxxxxxxxxxxxx
> Hi,
>
> I've been buried of late with work and have had little time to do anything
> Monad related. But I have a spanking new laptop (Dell Inspiron 9300 - it's
> awesome!) and am raring to go. I've been taking a look at setup of Monad
> and have a bunch of questions I'm going to want to ask!
>
> 1. Re profile.msh creation
> As I understand it, when msh.exe looks in both the all users\documents\msh
> folder and my documents\msh to find a profile.msh and subject to the
> execution policy runs them (all users running first). This is cool but why
> are these folders not created by default or why is there not a skeleton
> profile.msh (with no content) not provided?
>
> Suggestion: How about an option on setup to create and populate these?
I'll have to get someone else to followup on this with you.
>
> 2. MSHXML files rejected at first
> The first time you start Msh, it gets upset about the 8 mshxml files. Now
> I understand that these are pretty fundamental to the proper running of
> MSH - so why are they not trusted in the first place. But more
> importantly - I'm not clear on what is not trusting what. Is it MSH that
> does not trust the digital signature on the XML docs? If not, why not? Is
> there a certificate somewhere that should/could be provided? This is a
> poor user experience.
>
> I'm thinking here about larger scale deployment - you can deploy with a
> machine startup script easily enough, but I'd like to automate whatever it
> is I need to automate in order to get MSH to run smoothly. Is there a cert
> I need to install?
Thomas, this goes back to the many discussions we had at the PDC regarding
the default security mode. Since the MSHXML contain scripts we cannot run
them when in Restricted mode for the ExecutionPolicy setting. I agree that
this may not be the best user experience but it is our stance that we will
be secure by default. The about-signing help topic that gets referenced in
the error message provided when these fail to load should give the user
enough information to come to a decision on which mode they want to run in.
>
> 3. Titanic support?
> Is there, is there going to be, support for Msh on Itanium. There is a
> version of the CLR, but I suspect the testing load is such that it does
> not make sense given only 3 people are actually using this platform
> <grin>. What is the Itaniuim support story for V1?
>
This is still not completely clear to us yet. We are currently testing on
Itanium until we know for sure whether the platform will be supported by the
likes of Exchange, MOM, etc.
> 4. Language support
> At present, at least so far as I can tell, the only language supported in
> B2 is English (well American, but let's not split hairs). What is the
> plan? I am guessing that RTM will add German, Spanish, French, Italian,
> Japanese, Korea, both CHT and CHS and CS. Is this all?
>
These are the current languages that we plan to localize to when we ship
with Exchange. Pending on other ship vehicles that we are investigating we
may add to this list. For instance, if we release to the web as a Windows
component we will be localized to all the languages that Windows gets
localized to.
> Also, what will Monad look like? I am assuming all keywords etc are fixed
> to their english names. Thus if a german wanted to see pictures of his
> wife's dog, he might type
>
> $MeinStuffen = ls | where {$_.name -match "hund" -and '$_.name - match
> "Frau" }
>
> Same for Japanese etc?
>
> What about support for Arabic script?
>
Anything that will be used in scripts that may be run on machines in
different locales are not localized. All keywords/operators in Monad are
language invariant (meaning they don't change when the product is
localized). Since most are either US English or acronyms for US English
words, these will remain as such. All cmdlet/script names can contain any
Unicode character (except \ and -) but they are not localized. So the
cmdlets and providers that we produce will always have US English names and
will not be localized. This does not prevent cmdlets being developed with
Japanese names.
> 5 Deployment via Group Policies
>
> It looks like deployment via software group policy does not work (although
> this may just be a bug), but I can deploy via startup script. I'd like
> some idea of recomendations for best practice deployment via GP? Are there
> any?
>
I'll follow up with the setup guys.
> At present my best advice is to deploy using either a machine start up, or
> a user logon script. The former is better, IMHO, if you have the ability
> to bounce the server. I have a working script file that installs both the
> CLR and Monad. But I've yet to work out what to do around profile.msh, or
> how to solve the mshxml problem via a setup script.
>
> Comments welcome.
>
> Thomas
>
> --
> Thomas Lee
> doctordns@xxxxxxxxx
> MVP - Admin Frameworks and Security
.
- Follow-Ups:
- Re: [msh] Some msh setup questions
- From: Thomas Lee
- Re: [msh] Some msh setup questions
- From: lee . holmes
- Re: [msh] Some msh setup questions
- From: lee . holmes
- Re: [msh] Some msh setup questions
- From: Keith Hill
- Re: [msh] Some msh setup questions
- Prev by Date: Re: Colorize Get-Childitem Output
- Next by Date: Re: [msh] Some msh setup questions
- Previous by thread: Re: Microsoft need to fix a 404 with Monad.
- Next by thread: Re: [msh] Some msh setup questions
- Index(es):
Relevant Pages
|
