I've had a look at the chef community cookbook for installing sql server and it appears that it's tailored for installing SQL express, but I can't seem to work out how to install a standard or developer edition.
The README on the GitHub page (https://github.com/chef-cookbooks/sql_server) says you can just point it to any installation package, however I can't see how you would do this for an ISO (or even the extracted contents of an ISO) given that there's no single EXE package on the ISO media.
Am I missing something obvious, or will I need to roll my own recipe for installing SQL from an ISO (or contents of ISO)? Ideally I would like to host the installation media on a central package repository behind my firewall.
Option 1:
Customized cookbook is the best option for you use case. Like you said, host .ISO on central repo and create a cookbook that mounts the .ISO drive to run the installation. You should leverage that cookbook template and re-write that windows_package block in the server.rb to install using keyword 'source' with path to the mounted installation files. However, this will be a major work (from past experience...) so if you have only one or two nodes that need to run the cookbook, go with Option 2.
Option 2:
If you have only one or two nodes that need to run the cookbook, I would suggest you to run the basic 'sql_server::server' then upgrade to the version you want using the GUI with the PID product key.
Note that this process can be automated as well using Powershell script. If you are familiar with Powershell, you can automate it using powershell_script block.
ISOs are intended for DVD images but if you have an ISO shredder (search online for free tools) you'll see a setup.exe in there. Run that and it'll bring you to the installation center where you can choose to install a new instance and do a bunch of other things. It's a wizard type interface so just read the instructions on each page and you should be able to provide the relevant info where needed to successfully complete the installation
Related
On my domain server 2012r2I am trying to deploying office 2007 but not all of the office I need to install only excel and word
I found an .msi file within the dvd installation and found many .msi packages
called ExcelMUI.msiand WordMUI.msi at directory
...\English\Excel.en-us\ExcelMUI.msi
...\English\Excel.en-us\WordMUI.msi
can I use them to deploy only excel and word through domain server 2012r2?
are they valid as .msi packages installer ?
Best Guess: I wonder if those MUI-setups are Multilingual User Interface setups. I think you should get on a virtual machine and try to run the setup.exe instead (if there is one) and then go to "Custom" or equivalent to see if you get a feature selection dialog. Then you should select Word and Excel to install fully and you can disable most other features (don't disable the shared features, just the other apps would be my suggestion - Outlook, PowerPoint, etc...). It is possible that those MSI files you mention can be used directly. You could try to run them - but only on a virtual of course. Or on a computer which does not matter - test computer of some sort. Look for a custom option and a feature dialog there too. Sorry, all I can suggest without installation media access.
Sure?: With all that said, Office on a domain server? Do you mean domain controller? (hope not). Sounds like a very dangerous move if you ask me - with all the security holes Office contains. At least make sure to run Windows Update or Office Update or whatever mechanism you have to deploy security fixes. Can I be curious and ask why the server needs Office? Is it for automation only?
Viewer for MSI Files: You can open and inspect MSI files using the free tools Orca, SuperOrca or InstEd (links towards bottom). I have an old answer on superuser showing how MSI features can be seen inside the MSI file.
I have 3 2008-style SSIS packages that I think I've done a pretty good job upgrading to the 2016 tooling. I've migrated to Project Deployment at the top level and I'm using project params - it all seems like a big improvement.
My first problem is that when I deploy to the server, it seems to succeed, but the Integration Services explorer mode in SSMS shows no packages in the place I expect to see them. The new folder is there but there's nothing in it. I was able to use 7zip to uncompress the .ispac file in the /bin folder which is being deployed and it does indeed contain the .dtsx files that I expect to see.
When I deploy, the deployment wizard lists the .ispac file Path under Source section, but not the individual packages. That's probably fine but I'll mention it in case I should see the individual packages listed.
I also notice that there's an option to "Convert Deployment Model" under the Visual Studio project's SSIS Packages section - that's separate from the "Convert to Package/Project Deployment" at the project-level. It's also separate from the "Upgrade All Packages" option that has already been done and for which there are no remaining upgradable packages.
When I run the "Convert Deployment Model" wizard and try to "Next" past the screen where the packages are listed as "Not loaded" Status, I get an error that "One or more selected packages are not ready" an an Error status on all packages with the message that The variable "$Project::ServerB" was not found in the Variables collection. The variable might not exist in the correct scope.
#[$Project::ServerB] is indeed a variable in all of the packages. And in at least one of the xml content of the package files I can see it listed in just the one place. In the editor (the Expression field of the SQL Connection Manager) where we use the variable this project parameter evaluates to the configured value just fine.
What is this "Convert Deployment Model" option anyway, separate from the "Convert to Package/Project Deployment" option? Are they the same, and the one on the "SSIS Package" folder just failing to validate the conversion (back to Package Deployment) because there are project parameters that the resulting Package Deployment mode doesn't support, hence the error?
And most importantly, why aren't my packages actually getting deployed? Is this deployment model thing just a red herring at this point? What should I be seeing?
Thanks!
I was looking in the wrong spot. In SSMS, I see them under the Database Engine side of the Object Explorer, but not under the Integration Services side. Integration Services had a folder that might have been carried over from the old deployments and seems no longer necessary. Under the database there is a new "Integration Services Catalogs" folder that now shows the projects along with the expected deployed packages.
I guess the "Convert Deployment Model" was just a distraction.
While configuring the SQL Server 2012 Master Data Services, I am having following problem
The required .svc handler mappings are not installed in IIS.
What I want to do is that, I want to query my database using a URL so that I can retrieve data directly using the URL it self just like we can store the querystring parameters into SQL Server
How do I deal with it, I followed several documents but not any ideas.
To fix this issue, open a command prompt and go to the .NET directory
(for example %windir%\Microsoft.NET\Framework64\v4.0.30319).
Run the command: aspnet_regiis –i
For further details check:SVC Handler mapping error in MDS Configuration Manager
I've come across these types of errors a few times when installing MDS, the problem usually comes about because just having IIS installed is not enough, there are loads of other role services and features that you need to enable and install as well which the setup program doesn't tell you about.
Thankfully they are all documented here:
Web Application Requirements (Master Data Services)
And, if you've missed any, you can go back, install them and then re-launch the configuration tool to complete the setup without having to re-install MDS from scratch.
I download jdeveloper studio edition and install it in C:\Oracle\Middleware
then I install weblogic instance using C:\Oracle\Middleware\wlserver_10.3\common\bin\config.exe
to C:\myproject\domains\myweblogic
Then download DMS_11.1.0.0.0_WINDOWS.zip and install it to C:\Oracle\Middleware\Mobile.
thereafter cant start
C:\Oracle\Middleware\Mobile\Mobile\Server\bin\runmobileserver.bat
unless i change the variable to this batch file
set DOMAIN_DIR=C:\myproject\domains\myweblogic
what do I do next to see that it works?
is there a simple example that creates a sigle table and synchronized between server and mobile clients?
very difficult to find information on this technology. interfere very popular tags (Oracle, Database).
If you install Database Mobile Server directly in the WebLogic directory, you will not need to edit the batch file. For instance, I believe the default install directory is:
C:\Oracle\Middleware\wlserver_10.3
So if you used the default install directory, you would install Database Mobile Server there, with no added 'Mobile' or other directory. If you chose to install WebLogic elsewhere, then replace the above with that directory.
There is another small issue to be aware of.
The installer will give you warning about installing in a non-empty
directory. You should click through the warning. This is a known issue
documented in the Release Notes.
Regarding your other question about a demo, there is a Java demo found in
<MOBILE_HOME>\Mobile\Server\demos\consolidator_api
You will need to download a client and perform a sync, which is documented here:
http://download.oracle.com/docs/cd/E22663_01/doc.11100/e22681/instsqlite.htm#BABGAACI
I hope that helps, good luck with your project. Let me know if you have further questions.
Eric Jensen, Oracle PM
I'm just trying to understand SSIS packages a bit better and how they are deployed. Correct me I'm wrong but for any deployment, I believe there needs to be at least two files a .SSISDeploymentManifest and a .dtsx. The .SSISDeploymentManifest acts as the equivalent windows installer package which points to the .dtsx. The dtsx is the actual package of "stuff" that is referenced as an external file some how when you run the installer. When you install it, the package gets added to a list of ssis packages for that instance.
My further questions:
If i wanted to keep previous version of the same package, can I just copy the bin directories with the two above files and keep separately should I need to roll back to a previous package?
Where are these packages installed to? How does SSIS know where the packagess are?
Correct me I'm wrong but for any deployment, I believe there needs to
be at least two files a .SSISDeploymentManifest and a .dtsx. The
.SSISDeploymentManifest acts as the equivalent windows installer
package which points to the .dtsx. The dtsx is the actual package of
"stuff" that is referenced as an external file some how when you run
the installer. When you install it, the package gets added to a list
of ssis packages for that instance.
Your assumptions are mostly correct. You don't need the deployment manifest, but it can be handy. Also, you don't need to deploy to the SQL Server instance. You have the option to deploy to the file system as well. I'll explain both below.
Regarding your 1st question:
Version Control:
Make sure you're developing and checking in your dtsx packages via visual studio. Label your releases in sourcesafe or whatever version control you're using. If you are checking in and labeling, then you should be able to easily roll back to a previous version. As you mention, you also can just save a copy of your old bin directory but naturally put them in dated subfolders or something. However, this does not take the place of proper version control.
Regarding your 2nd question:
Deployment:
As the other poster states, you first have a decision to make:
a) Deploy packages to the file system
b) Deploy packages to MSDB
There are benefits to each, and everyone has their preference. I have used both, but I prefer the filesystem because it's more transparent, however there is more to maintain.
See this post for much more on this: http://blogs.conchango.com/jamiethomson/archive/2006/01/05/SSIS_3A00_-Common-folder-structure.aspx
The code is in the dtsx package. Generally,in order to make your packages portable you also abstract your connection strings and other configurable information into a config file (.dtsconfig) or environment variable (no file needed). See BOL to learn more about configuration.
The manifest file contains metadata about which dtsx and config files to install. If you open one, you'll see it's a simple readable xml file.
The manifest file makes it easy to hand over to a DBA to deploy (ask them to double-click the manifest file and follow directions, but they'll need instructions.
To me, the manifest file is more useful for deploying to SQL Server than to the file system. Really, all it does is make a copy of the dtsx and config files and puts them where you tell it. You could just as easily instruct the DBA to copy your dtsx files to a common folder on the server, and the config files to another folder on the same server.
Then when you schedule your jobs using SQL Agent, you specify that you're going to run an SSIS package that is stored on the file system and browse to where it's located. If you're using configurations, then there's a tab to specify where the config file is located.
There is so much to know about configuring/deployment/versioning of SSIS packages. But hopefully this will get you started on the right path.
When you export your DTS packages using the Import/Export Wizard in SQL Server you have the option of saving them to SQL Server or locally on the file system.
Regarding the versions of your SSIS packages, you need to query SSISDB to extract the version numbers. It's annoying this kind of info isn't shown directly in the Management Studio but, until it is, someone may find this useful:
SELECT prj.[name] as Project
,pkg.[name] as Package
,pkg.[version_major]
,pkg.[version_minor]
,pkg.[version_build]
FROM [SSISDB].[internal].[packages] as pkg
JOIN [SSISDB].[internal].[projects] as prj
ON pkg.[project_id] = prj.[project_id]
ORDER BY prj.[name]