I want to create a template using powershell but I cannot seem to figure out how to set a Minimum Supported CA for the template. I was never able to figure out how to duplicate a template, just create a new one.
My code is as follows
$temp = ([ADSI]"LDAP://RootDSE".ConfigurationNamingContext
$ADSI = [ADSI]"LDAP://CN=Certificate Templates,CN=Public Key Services, CN=Services,$config"
$temp = $ADSI.Create("pKICertificateTemplate","CN=Web Server 2008-2")
$temp.put("distinguishedName","CN=Web Server 2008-2,CM=Certificate Template,CN=Public Key Services,CN=Services.$Config)
$temp.SetInfo()
This works to create an actual template, but I want the template to be created using Windows Server 2008 Enterprise as the Minimum Supported CAs
In ADCS, a version 1 cert is Win200, version 2 is 2003, and version 3 is 2008.
I don't have a lab to verify in, but I think you need to set the template schema to 3:
$temp.put("msPKI-Template-Schema-Version","3")
$temp.put("msPKI-Template-Minor-Revision","0") # Not sure if you actually need this.
"Source..kinda"
As a workaround (not for every scenario), you can duplicate/set a certificate template manually once (on your CA) and export that template using ldifde (on your DC). E. g., you duplicated the Webserver template and called it Webserver Custom:
ldifde -m -d 'CN=WebserverCustom,CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=contoso,DC=com' -f .\webservercustom.ldf
Later, in some kind of automation, you can import that template by issuing:
ldifde -i -f .\webservercustom.ldf
Related
On a TYPO3 project I'm working the Production/Staging (or Production/Dev, or any other) environment is protected by HTTP BasicAuth (basic access authentication).
The instance get's deployed via typo3/surf.
At some point typo3/surf must create a temporary php file, which can be accessed
later: after the switch was done and the new deployment is reachable via the frontend.
How can I configure typo3/surf to access the previously generated OPcache clearing script via the frontend on a BasicAuth protected environment?
Configuring typo3/surf to reset the PHP OPcache1
Four steps are basically necessary to configure the OPcache clearing/reset script:
Set task options for \TYPO3\Surf\Task\Php\WebOpcacheResetCreateScriptTask
Add task \TYPO3\Surf\Task\Php\WebOpcacheResetCreateScriptTask the an early stage (e.g. package but definitely before transfer)
Set task options for \TYPO3\Surf\Task\Php\WebOpcacheResetExecuteTask
Add task \TYPO3\Surf\Task\Php\WebOpcacheResetExecuteTask after stage switch
Here are the necessary snippets for your onInitialize function2 within your deployment configuration script:
Set task options for the "Create Script Task":
Since the "Respect WebDirectory" patch, the path to the script must not to be configured manually as it automatically uses the right WebDirectory path (which is set via options beforhand).
If you are using an older typo3/surf version or you have any special requirement you can set option scriptBasePath to set the absolute path to the resulting file:
# In this example, I have to set the absolute path for the resulting php file.
# Since the deployment run in GitLab CI I get the path to the root of the project's GIT
# repository via the environment variable `CI_PROJECT_DIR`. Since the path to the webDirectory
# inside the GIT repository is `<GitRepoRootFOlder>/app/web` I add it manually and concatenate
# it as final string for the option `scriptBasePath`:
$workflow->setTaskOptions(\TYPO3\Surf\Task\Php\WebOpcacheResetCreateScriptTask::class, [
'scriptBasePath' => \TYPO3\Flow\Utility\Files::concatenatePaths([getenv('CI_PROJECT_DIR'), '/app/web']),
]);
Set task options for the "Execute Task":
At this point, we provide username and password
$workflow->setTaskOptions('TYPO3\\Surf\\Task\\Php\\WebOpcacheResetExecuteTask', [
'baseUrl' => $application->getOption('baseUrl'),
'stream_context' => [
'http' => [
'header' => 'Authorization: Basic '.base64_encode("username:password"),
],
],
]);
Activate both Tasks:
$workflow->beforeStage('transfer', \TYPO3\Surf\Task\Php\WebOpcacheResetCreateScriptTask::class, $application)
->afterStage('switch', \TYPO3\Surf\Task\Php\WebOpcacheResetExecuteTask::class, $application);
This answer shows only the necessary parts for the OPcache reset process!
Please check also the TYPO3 CMS deployment configuration example in the official documentation.
Footnotes
1 This answer is based on typo3/surf GIT branch dev-master, version 2.x
2 Example where to place the mentioned snippets:
$deployment->onInitialize(function () use ($deployment, $application) {
/** #var SimpleWorkflow $workflow */
$workflow = $deployment->getWorkflow();
# the mentioned snippets have to be placed next to your existing configuration
});
I'm trying to setup a deploy process that targets 16 web sites each hosting an instance of the same application.
Websites and AppPools are named as such:
appServer1:
app10.site.com
app11.site.com
app12.site.com
app13.site.com
appServer2:
app20.site.com
app21.site.com
app22.site.com
app23.site.com
etc.
etc.
...with each website having a correspondingly named AppPool.
I am desperately trying to determine how to use a single Deploy NuGet Package step to target all of these websites/app pools using variables and a combination of powershell scripts if possible.
I'd like to have a single step where I can variable substitute the website and app pool names. As this is the only difference. I basically need the equivalent of being able to loop the nuget package step passing it a list of website and app pool names. I cannot simply use variables because I can only resolve to the machine level with variable scoping.
Create list of all Website and AppPool names, iterate them passing each value to a Step for execution. ForEach processing step for lack of better words.
I do have the ability to rename the AppPools if need be for a more consistent pattern, but I cannot change the website names
Any ideas would be greatly appreciated.
http://help.octopusdeploy.com/discussions/questions/3481-every-website-in-the-deploy-has-a-different-apppool-and-website-name-how-to-deal-no-other-differences
There's a lot to your question, but I'm going to take a stab at explaining our approach, in hopes of jogging your creative juices.
tl;dr
simply put, use your own powershell scripts to install the web-application. In there you can set the app pool name on a per website basis
For starters, we do do a separate deployment step for each project. The scripts we use will allow you to do all deployments from a single deploy.ps1 (including unique appPool names), but we find that it really helps keep each deployment nice and lean, and easy to manage. Each project get's it's own nupkg and therein contains the predeploy.ps1, deploy.ps1, and postdeploy.ps1 as well as a folder of build/deploy scripts that we've open sourcesd, and a folder of environment config xml files.
A sample of an environment config would be this. The name is simply [envName].xml
<!-- environments\Production.xml -->
<environmentSettings>
<webSites>
<app>
<physicalPathRoot>c:\inetpub</physicalPathRoot>
<physicalFolderPrefix>appname</physicalFolderPrefix>
<siteProtcol>https</siteProtcol>
<siteName>appname.tld</siteName>
<siteHost>appname.tld</siteHost>
<portNumber>443</portNumber>
<appPath>/</appPath>
<appPool>
<name>appname.tld</name>
<!-- valid identityTypes are: [LocalSystem, LocalService, NetworkService, SpecificUser, ApplicationPoolIdentity] -->
<identityType>NetworkService</identityType>
<!-- Set this value to the User the Service will run under in the format DOMAIN\username -->
<!-- If Running as 'NetworkService' then 'NT AUTHORITY\Network Service' is used -->
<userName>NT AUTHORITY\Network Service</userName>
<!-- Leave blank unless using SpecificUser -->
<password></password>
<maxWorkerProcesses>5</maxWorkerProcesses>
</appPool>
</app>
</webSites>
<serverDatabase>
<name>database_name</name>
<connectionString>REPLACED BY OCTOPUS</connectionString>
<providerName>System.Data.SqlClient</providerName>
</serverDatabase>
</environmentSettings>
You can see in the corresponding Get-EnvironmentSettings.ps1 where we load up the config, and then update it with any Octopus variables. This is the trickiest part, because we use dot-Notation to update the paths (case sensitive).
Our octopus variables really only contain information that is secret, as everything else lives in [environment].xml
| Name | Value | Scope
--------------------------------------------------------------------------
| webSites.app.appPool.password | supersecret | Production
So now a typical deployment script simply imports the modules, grab environmentSettings, update config, and install the web app.
# Top of the script, get Octopus environment and version
param(
[string] $version = $OctopusPackageVersion,
[string] $environment = $OctopusEnvironmentName
)
# Make sure a failed deployment actually fails
$ErrorActionPreference = "Stop"
# Import the modules
$currentDir = Split-Path $script:MyInvocation.MyCommand.Path
$moduleDir = "$currentDir\modules"
Import-Module BuildDeployModules
# Grab the environment settings
$environmentSettings = Get-EnvironmentSettings $environment "//environmentSettings"
$databaseSettings = $environmentSettings.serverDatabase
$websiteSettings = $environmentSettings.webSites.app
# update the config
Update-XmlConfigValues $currentDir\website\Web.config "//appSettings/add[#key='databaseName']" $($databaseSettings.name) "value"
Update-XmlConfigValues $currentDir\website\Web.config "//connectionStrings/add[#name='databaseConnection']" $($databaseSettings.connectionString) "connectionString"
Update-XmlConfigValues $currentDir\website\Web.config "//connectionStrings/add[#name='databaseConnection']" $($databaseSettings.providerName) "providerName"
# Install the web application
Install-WebApplication $environment $websiteSettings $version "anonymousAuthentication"
In doing all of this, the web application is installed into IIS with a specific application pool, and appropriate config transforms without relying on any unknowns.
Our nupkg structure looks something like this
appname.1.2.3.4.nupkg
environments
dev.xml
staging.xml
qual.xml
production.xml
modules
[all of our build modules]
website
[all of our website files]
This is super repeatable, easy to maintain, and easy to edit config. Hope it helps
Installer is installed typically using GUI or console, we need unattended installation capability as well. Running the installer like this (in Linux):
myapp -q -c -varfile myfile.var
Installer installs the software successfully. Problem is it ignores some variables (not all variables). It doesn't read values for zServerPort$Long and zShutdownPort$Long variables and instead applies the default values configured in application.
Varfile is provided below
#install4j response file for Sw 4.6
#Mon Aug 11 19:55:46 PDT 2014
sys.adminRights$Boolean=true
choiceIsLicenseSelected=true
zDBUserName=user
zLaunchDesktopPostInstall$Boolean=false
zDBPassWord=password
sys.languageId=en
sys.installationDir=/opt/mydir
zServerPort$Long=85
zLicenseFilePath=/home/mydir/Desktop/license.lic
zMysqlPath=/usr/bin/mysql
zMysqlCnf=/etc/mysql/my.cnf
zDbPort$Long=3306
choiceInstallDir=/opt/mydir
zShutdownPort$Long=8015
zServerPort, zShutdownPort, choiceInstallDir, zMysqlPath are all installer variables. Reordering the variables didn't work either. Is the problem due to data type being Long ?
Is there a way to pass the values of these two variables zServerPort, zShutdownPort in some other way ?
Other idea am thinking is whether if the installer can know that it is being run in unattended mode and read these variables from command line ?
Most likely, the defaults are applied with a code snippet and not through the initial values of form components.
In those code snippets (i.e. in a "Run script" action"), you have to check whether the value is already defined or not. For example:
if (context.getVariable("variableName") != null) {
context.setVariable("variableName"), 100L);
}
I'm having a few problems breaking out an MsBuild package+deploy command into two separate commands. (I need to do this to pass additional parameters to MsDeploy).
The command that works fine looks like this:
msbuild "src\Solution.sln"
/P:Configuration=Deploy-Staging
/P:DeployOnBuild=True
/P:DeployTarget=MSDeployPublish
/P:MsDeployServiceUrl=https://192.168.0.1:8172/MsDeploy.axd
/P:DeployIISAppPath=staging.website.com
/P:AllowUntrustedCertificate=True
/P:MSDeployPublishMethod=WmSvc
/P:CreatePackageOnPublish=True
/P:UserName=staging-deploy
/P:Password=xyz
The separated packaging command looks like this:
msbuild "src\Solution.sln"
/P:Configuration=Deploy-Staging
/P:DeployOnBuild=True
/P:DeployTarget=Package
/P:_PackageTempDir=C:\temp\web
which works fine. But then the MsDeploy portion:
msdeploy
-verb:sync
-allowUntrusted
-usechecksum
-source:manifest=
'src\WebProject\obj\Deploy-Staging\Package\WebProject.SourceManifest.xml'
-dest:auto,ComputerName=
'https://192.168.0.1:8172/MsDeploy.axd?site=staging.website.com',
username='staging-deploy',password='xyz',authType='basic',includeAcls='false'
-enableRule:DoNotDeleteRule
fails, with the following error in WmSvc.log
wmsvc.exe Error: 0 : Attempted to perform an unauthorized operation.
setAcl/C:\temp\web (Read)
ProcessId=15784
ThreadId=31
DateTime=2011-03-30T14:57:02.4867689Z
Timestamp=3802908721815
wmsvc.exe Error: 0 : Not authorized.
Details: No rule was found that could authorize user 'staging-deploy',
provider 'setAcl', operation 'Read', path 'C:\temp\web'.
(and several more Read/Write operations)
Something is clearly going wrong with the paths it's trying to access (as it works fine with the other method) - I'm not sure it's even trying to use the iisApp targeting correctly, and at the moment I don't think the correct web.config's will be deployed either.
I've got this fixed now - I needed a different command to the one the automatically generated .cmd file was using, but comparing the two allowed me to fix it up (thanks #Vishal R. Joshi)
The differences I needed was:
basic authentication
allow untrusted certificates
?site=staging.webserver on the end of the MsBuild.axd path, as with my original command
override the IIS Web App name that is set in the params file
enable the do not delete rule
The winning command is as follows:
msdeploy
-verb:sync
-allowUntrusted
-source:package='src\WebProject\obj\Deploy-Staging\Package\WebProject.zip'
-dest:auto,ComputerName=
'https://192.168.0.1:8172/MsDeploy.axd?site=staging.website.com',
username='staging-deploy',password='xyz',authType='basic',includeAcls='false'
setParamFile:
"src\WebProject\obj\Deploy-Staging\Package\WebProject.SetParameters.xml"
-setParam:name='IIS Web Application Name',value='staging.website.com'
-enableRule:DoNotDeleteRule
-disableLink:AppPoolExtension -disableLink:ContentExtension
-disableLink:CertificateExtension
Hope this helps someone!
Add a delegation rule on the server using inetmgr to allow staging-deploy to carry out set-Acl operations.
Inetmgr -> Click on server node -> Management Service Delegation (in Management) -> Click Add rule to the right -> Choose the template labelled "Set Permissions for Applications" -> Accept defaults and click OK.
This should let you deploy any package or manifest with setAcl as long as the user you are deploying as, has permissions to the site you are deploying to.
You are able to specify the -setParam:name='',value='' flag when calling the MyProject.deploy.cmd file that is created when you generate a Package from a web project. The cmd is a friendly wrapper around msdeploy.exe, so you have no need to specify all the rest of the defaults.
Here's the details: http://evolutionarydeveloper.blogspot.co.uk/2013/05/specifying-environment-variables-at.html
I developped a VSTO SE Excel 2003 add in.
When launching and debuging the add in from visual studio, it works well.
But when I try to deploy it from my own install it never works.
To sum up, here is my install process:
the files are copied at the right location
I register the addin:
HKEY_CURRENT_USER\Software\Microsoft\Office\Excel\Addins\
with the appropriate values (Default, CommandLineSage, Description, FriendlyName, LoadBehavior, Manifest).
I also add entries in
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\ (with CLSID key including an UUID)
And HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID{xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}
with InprocServer32 (with the manifest name and path, the addinloader.dll fullpath), ProgID (with the assembly name (without extension)), Programmable and VersionIndependententProgID (with the assembly name too).
I set the fulltrust policy to the url of every assemblies using caspol -m -ag "xxx" -url "MyUrl\Assemblies.dll" FullTrust -name "name"
Do I miss something ?
In the deployment machine, check whether the following are available:
Currect version of VSTO Runtime
Office 2003 Primary Interop Assesmblies
regards,
yenkay...
A good way to debug VSTO installation/loading issues is to have VSTO show you all errors. To do that, create an environment variable called VSTO_SUPPRESSDISPLAYALERTS with the value 0, reinstall/repair your addin, then try running Excel again.
It looks like the problem is with your registry keys. Check out the following link:
http://msdn.microsoft.com/en-us/library/bb386106.aspx
Your Software\Classes and Software\Microsoft entries should be under the same key, either HKCU or HKLM. If you have one under HKCU and the other under HKLM, it messes up the addin.
So I think the registry entry HKEY_CURRENT_USER\Software\Microsoft\Office\Excel\Addins\ should be HKEY_LOCAL_MACHINE\Software\Microsoft\Office\Excel\Addins.
HTH...