This might be wrong place to ask this question.
I spent effort in setting up thr sharepoint 2010 2 tier farm. I have settled up the sql server databases required for sharepoint, installed on different machine. and sharepoint on another machine. it took around 6 days, but at the end i noticed that i have computer name with something "win43453-676" like this. where as my manager wants to to keep relavant name like "CentralAdminMachine" of central admin pc. if i changed the name of machine , i am unable to open even central administration site. is there any remedy to change this name in configuration database and all....?
There is both a PowerShell cmdlet and an STSADM command that allow you to change the server name. Both require that you first change the name through the standard Windows System control panel. After that (and a restart) you can use:
Rename-SPServer [-Identity] <OriginalServerName> -Name <NewServerName>
http://technet.microsoft.com/en-us/library/cc263117(office.12).aspx
or
Rename-SPServer [-Identity] <SPServerPipeBind> -Name <String> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-WhatIf [<SwitchParameter>]]
http://technet.microsoft.com/en-us/library/ff607556.aspx
There are some people who seem to recommend the STSADM (even though PowerShell is the Microsoft recommend way on SharePoint 2010) because it seems to work and not the give error that the PowerShell command does about feature dependency, but it looks like you can try either one.
And you may need to update your alternate access mappings to enable any custom URLs to work as well.
Related
I'm learning IT right now, and I have this situation.
The employee who was the administrator, got out of the company. But he doesn't leave a documentation to tell me which of my ADDC (Active Directory Domain Controller) is the PDC, I mean I'm interested to fin the global catalog and structure of my network.
Does you know a post from TechNet or some site to find this PDC in Windows Server 2008 R2?
You can either open Active Directory Sites and services, expand sites -> servers and look at the NTDS settings of each server you have, there will be a tick box on the general tab that will be checked if the server is a global catalog.
Alternatively, if you have quite a lot of servers and don't want to have to do this for each one, you can use nslookup:
Find a list of global catalogs using nslookup
As for PDC though, these haven't really existed since windows NT, there is however a PDC emulator FSMO role which is held by one domain controller that you can find using the following command:
dsquery server -hasfsmo pdc
You can see the other FSMO roles here:
Identify Operations Master Roles
You can display the Global Catalog Servers in the domain you are logged in to using Nslookup.exe:
Open a CMD.EXE window.
Type the following command and press Enter:
nslookup gc._msdcs.%USERDNSDOMAIN%
Run the following from a command promt:
nslookup
set type=serv
_gc._tcp."FQDN"
I was tasked to research migrating a 2007 MOSS to ShrePoint 2010. Got two servers, one is runing a SQL 2008, and the other has SharePoint 2010 already installed. I need to migrate several publishing and team sites and their corresponding databases. I started reading this article on Upgrade and Migration for SharePoint Server 2010
, then another at Migrate an existing server farm to a 64-bit environment but have a little confusion about wheather I'm migrating, upgrading, or moving the system, as each article defines steps to do this.
Current 2007 MOSS and SQL 2005 are on Windows 2003 32-bit OSs. The new system which at this point in not part of the farm but is in the same domain, are a 64-bit blades running Win 2008 OS with SQL 2008 and SharePoint 2010 - all already instaled / Central Admin site already running. The whole farm consists of 2 severs I just described.
Thanks for reading my post and appreciate any pointers!
Risho.
I just went through this exact scenario. The documentation on the various methods can get confusing. Note, for simple farms (no BDC, etc.), all you really need is the content databases. Here's a simple way to accomplish your goal:
On existing, 2007 farm, make sure it's Service Pack 2
On existing 2007 farm, run stsadm -o preupgradecheck
Fix any errors identified by the upgrade checker
Backup the Content database(s) you want to migrate (old 2007 farm)
Restore Content database(s) to new SQL server
Create a new Web Application on the new 2010 farm. A new WebApp will need to create a Content DB, so name it something like WSS_Content_Temp. This will be the WebApp that you will restore your Content to, so name the WebApp appropriately. You'll remove the content DB, so name it whatever you want.
From PowerShell, run: Test-SPContentDatabase -name <NameOfMovedContentDB> -webapplication http://yourNewWebApp
Fix any errors identified
From PowerShell, mount the newly restored/moved database. Run Mount-SPContentDatabases -name <NameOfRestoredContentDB> -webapplication http://yourNewWebApp. You should see a progress % number that is incrementing. Depending on how big your content databases are, this could take a while (30+ minutes)
From Central Admin -> Application Management, select/highlight your new Web Application.
The go back to Central Admin -> Manage Content Databases, and remove the original, temp Content DB (WSS_Content_Temp)
At this point, if all went well, you should be able to browse to http://yourNewWebApp and see all your content.
Rinse and repeat as needed.
This is my first try of Visual Basic 2010 Express, though I have 10 yrs+ experience in VBA.
I'm running Windows XP SP2 on a desktop pc with following installed:
Visual Basic 2010 Express... just installed!
SQL Server 205 Express ... been running on pc for 12 months
I've created a new DB in SQL for my test application, but have not added any users or permissions to it as I'm using Windows authentication.
I've created a new Windows Forms Solution in VB2010EXP and tried adding a new Data Source for my new SQL DB, but it keeps giving error message about not having rights ot the db.
2 days of searching on the web has confirmed many others with similar issues, but no obvious solution. Eventually I find a few threads about permissions and moving the mdf into the root of the HDD, so try moving my mdf file up closer to the root of the Hard Drive
msf was in C:\Documents and Settings\_SharedData\Application_Data\MSSQL2005\Data\
now in C:\SQL2005\Data\
Now I can finally add a data source to my Db and start to use VS.
Problem is now occasionally when I am workng in VB and then go to the SQL Management Studio and try and view/change my DB, it gives an error and I cant access my DB. I then have to detach and re attach to my DB before I can work on it.
So my questions are:
Surely the location of my MDF file
should not be critical???
Do I need to add a user and
permission to my DB or should VB be
able to deal with this automatically
as I'm using windows authentication
Are then any known issues with
VB/VS causing errors in SQL
Managment Studio?
Thanks in advance
Grant
SQL Server runs on a different Windows Account to the one you use. You can check this by going to services (Run > Services.msc) and under SQL Server, go to properties and the Log On tab. I think by default 2005 uses the 'Network Service' system account. Now the reason you can't attach an MDF sat inside your documents folder is that account doesn't have access to your documents. You could give it permission, but you're much better off having the databases closer to the root as you have done.
Your connection to the database is driven by the connection strings you use. My personal preference is to create SQL Login accounts for my applications, and give them the least possible permissions they require. You could do the same using a Windows Account if you prefer.
I'm sure there are a couple. What is the error you are getting that prevents you accessing the Db? If we can see this error we may be able to help better.
Hope that helps.
Background: One of my coworkers has a project that is written in VBA to use MS Access 2003 Run-time as a front-end for a MSSQL database. It's an internal project used by multiple users operating in terminal sessions on a Server 2008 R2 box.
Problem: Every time the Access project is opened, users are greeted with a Security Warning:
This file may not be safe if it contains code that was intended to harm your computer.
They have the option to Cancel or Open. The users would like to be able to skip this prompt.
Since the full version of Access is not installed, users cannot alter their individual security levels and the VBA project cannot be signed with selfcert.exe certificates. (I'm not sure that it would work for multiple users anyway?).
Ideal fix: I'm hoping there's GPO or registry key that alters security settings for Access Runtime, but am open to other suggestions. I'm sure the problem could be fixed by purchasing a license for the full version of Access and a certificate from an approved CA, but this project doesn't have any budget for it.
Update: Have confirmed that the guy who put this project together did it in Access 2003 and does not want to re-test for Access 2007/2010 runtimes. So we're stuck with 2003 Runtime.
Very late answer, but it might help someone. There is a way to do this. I created a shell for my Access apps (originally just to auto update my applications), and during this discovered you can completely workaround Access 2003 security (& 2007 etc with Remou's Trusted Locations).
Set the SecurityLevel in the registry, run the mdb via commandline, reset the registry.
Root: HKCU; Subkey: SOFTWARE\Microsoft\Office\11.0\Access\Security; ValueType: dword; ValueName: Level; ValueData: 1; Check: IsAccInstalled('11.0'); Flags: dontcreatekey
Level 1 = Low, No action; 2 = (Default) Medium, Prompt; 3 = High, Deny?
You can also run your mdb with COM, setting the SecurityLevel via COM before opening the mdb.
However COM wont work for runtime (and you cant identify the OS process later via a unique commandline as I needed to)
Answering this one just to say that no, there doesn't appear to be a way to avoid the security warning for Access 2003 Runtime without actually signing the project.
Is there a way in SQL Server Management Studio 2005 (or later) to change the Windows Authentication user (as you could in SQL Server 2000 and older)?
This is the general connection properties dialog(note the greyed out UID/PWD when selecting Windows Auth):
FYI - One workaround is to use runas but I'm looking for a solution that will allow me to work with multiple Windows accounts across multiple servers (and across multiple domains).
While there's no way to connect to multiple servers as different users in a single instance of SSMS, what you're looking for is the following RUNAS syntax:
runas /netonly /user:domain\username program.exe
When you use the "/netonly" switch, you can log in using remote credentials on a domain that you're not currently a member of, even if there's no trust set up. It just tells runas that the credentials will be used for accessing remote resources - the application interacts with the local computer as the currently logged-in user, and interacts with remote computers as the user whose credentials you've given.
You'd still have to run multiple instances of SSMS, but at least you could connect as different windows users in each one.
For example: runas /netonly /user:domain\username ssms.exe
Hold shift and right click on SQL Server Mangement studion icon. You can Run as other windows account user.
One other way that I discovered is to go to "Start" > "Control Panel" > "Stored Usernames and passwords" (Administrative Tools > Credential Manager in Windows 7) and add the domain account that you would use with the "runas" command.
Then, in SQL Management Studio 2005, just select the "Windows Authentication" and input the server you wanna connect to (even though the user that you can see greyed out is still the local user)... and it works!
Don't ask me why ! :)
Edit:
Make sure to include ":1433" after the server name in Credential Manager or it may not connect due to not trusting the domain.
None of these answers did what I needed:
Login to a remote server using a different domain account than I was logged into on my local machine, and it's a client's domain across a vpn. I don't want to be on their domain!
Instead, on the connect to server dialog, select "Windows Authentication", click the Options button, and then on the Additional Connection Parameters tab, enter
user id=domain\user;password=password
SSMS won't remember, but it will connect with that account.
The runas /netonly /user:domain\username program.exe command only worked for me on Windows 10
saving it as a batch file
running it as an administrator,
when running the command batch as regular user I got the wrong password issue mentioned by some users on previous comments.
For Windows 10:
Go to the Sql Management Studio Icon, or Short Cut in the menu:
Right Click > Select Open File Location
Hold Shift and right Click the shortcut, or ssms.exe file that is in the folder. Holding shift will give you an extra option "Run as different user":
This will pop up a login box and you can type the credentials you would like your session to run under.
A bit of powershell magic will do the trick:
cmdkey /add:"SERVER:1433" /user:"DOMAIN\USERNAME" /pass:"PASSWORD"
Then just select windows authentication
There are many places where someone might want to deploy this kind of scenario, but due to the way integrated authentication works, it is not possible.
As gbn mentioned, integrated authentication uses a special token that corresponds to your Windows identity. There are coding practices called "impersonation" (probably used by the Run As... command) that allow you to effectively perform an activity as another Windows user, but there is not really a way to arbitrarily act as a different user (à la Linux) in Windows applications aside from that.
If you really need to administer multiple servers across several domains, you might consider one of the following:
Set up Domain Trust between your domains so that your account can access computers in the trusting domain
Configure a SQL user (using mixed authentication) across all the servers you need to administer so that you can log in that way; obviously, this might introduce some security issues and create a maintenance nightmare if you have to change all the passwords at some point.
Hopefully this helps!
Did anybody tried "plain" runas without parameters? Those /netonly /savcecred all of them sound ambiguous and to me utter nonsense.
C:\Windows\System32\runas.exe /user:DOMAINX\OtherUser02 "C:\Program Files (x86)\Microsoft SQL Server Management Studio 18\Common7\IDE\ssms.exe"
This works just fine. No matter what, runas WILL ask you for the user password. Just type it and be security audit compliant.
The only way to achieve what you want is opening several instances of SSMS by right clicking on shortcut and using the 'Run-as' feature.